A few pointers in case anyone decides to follow this up further:

Zipfile execution is just a special case of normal zipimport: the
zipfile's name is placed at the head of sys.path and a (very) rough
equivalent of "import __main__" is then invoked.

So for zipfile execution to support password protected zipfiles, general
zipimport would need to support them as well.

However, this runs into the problem that invocation of the zipimport
module is largely implicit - the import engine invokes sys.path_hooks
entries (which includes ZipImporter automatically) for a given sys.path
entry and finds that, sure enough, ZipImporter recognises it and creates
an appropriate object to handle it.

So the trick lies in getting the password to the importer that needs to
know it in order to open the zipfile.

For the general case, you could create a new path hook that had a list
of filename pattern<->password pairs that could be placed in
sys.path_hooks ahead of the normal zipimport hook. If it saw a pattern
it recognised, it could use the appropriate password to open the zipfile
and return a corresponding importer object (you could do this largely
independently of the standard library itself - PEP 302 is expressly
designed to let third party developers run with this kind of idea).

That wouldn't help much with zipfile execution though, as you still
wouldn't have a mechanism for providing the password on the command line.