Using the query that Jeff included in his answer, namely:

SELECT '[' + u.user_name + ']' + '[' + p.proc_name + ']' AS [Id],
       '' AS [CatalogName],
       u.user_name AS [SchemaName],
       p.proc_name AS [Name]
  FROM sys.sysprocedure p JOIN sys.sysuserperm u ON p.creator = u.user_id
 WHERE ( u.user_name NOT IN ( 'SYS', 'dbo', 'rs_systabgroup', 'SA_DEBUG', 'ml_server' ) )
   AND ( ( LOCATE( TRIM( p.proc_defn ), 'CREATE PROC' ) = 1 ) OR ( LOCATE( TRIM( p.proc_defn ), 'ALTER PROC' ) = 1 ) )
ORDER BY u.user_name, p.proc_name

I did a little spelunking in my database. I have a stored procedure in my database which I haven't been able to create a function import for. The only way I was able to create one was to edit it and add a "SELECT 1" to the end of the stored procedure.

It turns out that the problem is not that the stored procedure was missing a SELECT 1. If you look at the second line of the WHERE clause in the query that Jeff posted, it's expecting the procedure definition to start with either 'CREATE PROC' or 'ALTER PROC'. In the very first character. The script that we wrote to propagate changes to our database schema to existing installs includes a comment:

/* Version 38 */

The proc_defn column for this stored procedure starts with this comment and the CREATE PROCEDURE statement is the very next thing after it.

I don't know why or how that comment made it into the proc_defn column in the system table, but it did. And if the query that Jeff included is the query that is indeed used by Visual Studio when it queries the database for the list of stored procedures, then this comment is the problem. Either the query needs to be modified so it ignores comments at the start of the procedure definition, like the parser does, or I don't know what.

To be thorough, I edited the stored procedure in question in Sybase Central. All I did was open the stored procedure & hit Ctrl-S to save it. Sure enough, the comment got moved after the CREATE PROCEDURE (after the left parentheses but before the first parameter). Jeff's query now sees this stored procedure.

And, when I run the Update Model from Database command in Visual Studio, sure enough, the stored procedure shows up in the list. I can create a function import and everything works. There is no SELECT 1 at the end of the stored procedure. Which I guess means I can go and delete those lines from the other stored procedures, except I'm probably not going to, yet. There are other fish to fry.

EDIT:

We break our changes up into versions. As we fix issues or implement new functionality, each version is a set of changes being made to the database in a block. There's a table in our database called "CarSystem_Versions". There's a row in that table for each version that has been applied to the database.

The script began as an export of the base database schema, followed by a series of blocks of statements, one for each version change.

Each version is coded in the following format:

/* Version x */
IF NOT EXISTS ( SELECT 1 FROM CarSystem_Versions WHERE VersionId = x ) THEN

    -- Version specific statements

    INSERT INTO CarSystem_Versions
        ( VersionId, VersionTitle, Description, VersionDate, LocaleId, CreatedDate, ModifyDate )
    VALUES
        ( . . . );

/* Version x */
END IF;
go

In looking over the script, there are four stored procedures that have this problem, only one of which I want to import. The blocks for these four versions are similar in that they look like this:

/* Version x */
IF NOT EXISTS ( SELECT 1 FROM CarSystem_Versions WHERE VersionId = x ) THEN

    ALTER PROCEDURE . . .

    INSERT INTO CarSystem_Versions
        ( VersionId, VersionTitle, Description, VersionDate, LocaleId, CreatedDate, ModifyDate )
    VALUES
        ( . . . );

/* Version x */
END IF;
go

Start with something like this and see if that does it. If it doesn't, I don't know how it happens.

I'm no longer sure about dbisqlc.exe. I know for a fact that this issue happens when the script is loaded into dbisql.exe and executed. And, just to make sure you've got everything you need, here's the DDL for the CarSystem_Versions table:

CREATE TABLE "DBA"."CarSystem_Versions" (
    "VersionId" INTEGER NOT NULL,
    "VersionTitle" VARCHAR(500) NOT NULL,
    "Description" VARCHAR(8000) NULL,
    "VersionDate" TIMESTAMP WITH TIME ZONE NOT NULL,
    "LocaleId" VARCHAR(50) NOT NULL,
    "CreatedDate" TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NOW(),
    "ModifyDate" TIMESTAMP WITH TIME ZONE NULL,
    PRIMARY KEY ( "VersionId" ASC )
) IN "system";

EDIT 2: We just finished some testing and we can verify that the IF NOT EXISTS followed immediately by the ALTER PROCEDURE command, when run in dbisql.exe, causes the comment to appear in front of the CREATE PROCEDURE in the proc_defn column. This happens even if the stored procedure's body is empty. If there's any other statement between the two, no comment goes into the column. Which is actually preferable, if you ask me.