If this is going to be done at all from a list box, I think it implies that the list of entry points must exist in a table first. So the question then becomes, how to get the names in a table. I can answer this question, but you might not like the answer. At least for AC97, this next part is true. I don't know (but doubt) that AC2K is any better than this.
There is no visible "hidden" table that lists module entry point names. MSysModules2 lists the names of objects that contain modules - but the modules themselves are stored as long binary objects. (I.e. compiled objects.) MSysModule2 does not list entry points so you cannot extract from there. The only way to get this is to write some code to find it and to then populate your table. The bad news is, this code is tough to write. The worse news is, Access isn't very efficient when doing some of things I will describe in a moment. The good news is, you only have to run it after you edit a general or class module.
General modules are part of the database in a collection called
CurrentDB.Containers!Modules.Documents
Each document in that collection is an object corresponding to one of the icons you see in your Modules pane of the DB window. You must open the module to see its contents. (DoCmd.OpenModule {module-name-to-be-opened})
But there is also such a thing as a Class module. Each form is part of the database collection called
CurrentDB.Containers!Forms.Documents
For reports, this is
CurrentDB.Containers!Reports.Documents
You must OPEN a form or report to see its contents. When opened, the form or report has a property called .HasModule, which is True/False. If you have a module for a given form or report, it is {opened-form-name}.Module - and you guessed it, you have to open that module to see its contents.
OK, now that we have open modules, you have to accept an ugliness - you have to READ the module to find its entry points.
Each module has a collection of lines, as
....module.Lines
which can be stepped through by enumerating the line number using ....module.Lines

syntax. The number of lines in the module is
....module.CountOfLines
So now, all that is left is a little loop to step through each line from 1 to CountOfLines for that module. In each line, you will do two InStr searches, trying to find declarations such as Function or Procedure. The text standing between the end of either of those keywords and the next open parenthesis is the entry point name. And because of the way you had to find it, you even know whether the entry is a function or a procedure.
So in order to populate this list you seek, you would have to open a recordset to your table that holds your entry point names.
Then you would step through all documents that could imply or express modules. This includes general modules and the class modules for all forms and reports.
For each module, you would step through all lines looking for the keywords you wanted.
For each keyword match, you would parse out the line to find the entry point name.
And for each entry point name, you would add a new record to the recordset. It is up to you as to how much extra info you would store during that update operation.
When you are done, your table lists all entry point names. You could, if you wished, have also stored the name of the place where it was found, what kind of entry it was, and the number of lines in the implied procedure. (That is a pseudo-property function you can look up, ProcCountLines.)
Now, what I told you is the Brute Force method. There is another way to do this that is SLIGHTLY better.
You could ALSO get to the point of the module being open. Then you could look at the modules count of lines. Then look a property .CountOfDeclarationLines to see how many declaration lines there are. Then step to one line past that count and use the .ProcOfLine pseudo-property function to find the name of the procedure associated with that line. Then find the pseudo-property function .ProcCountLines of that named procedure. Step through the module by adding counts to get to the next line after each procedure you found this way. Eventually you will add enough lines to "fall off the end" of the module.
Doing it this way, you will not find out whether the entry is a function or sub procedure. But you can still find the number of lines in it and its starting line, because the pseudo-property functions give you that much once you have the procedure name.