I'm sorry, but something about this train of thought makes little or no sense.
... the solution I'm looking for will allow me to put modules in the directory (i.e. a new module called Module4.pm) and then have the script automatically recognize the existence of this new mod.
What I don't understand is: if you create or install a new module, and you want to use it in an existing perl script, don't you have to edit that existing script anyway, to add whatever logic will be invoking the objects/methods/etc being provided by the new module? And if you have to edit an existing script anyway, why not go ahead and add the specific "use Newmodule;" statement at the top? Why is it a problem to do that?
If I had to maintain a setup like yours, where all the modules in a given location are being loaded into scripts implicitly, I think I might end up losing sanity... Some modules do not export their function calls by default, and this is done, in part, so that the programmer who uses the module has to declare specifically when he is using a particular function from the given module. This is good for maintenance, because it's easier to keep track of where stuff comes from.
Update: Another reason why modules don't export by default is, of course, to guard against the inevitable collisions in the symbol table when two separate modules happen to export the same name. I suppose that if you're in a situation where your scripts are being created automatically by some other script(s), it might make sense to have this sort of "automatic scan and load" operation over a whole module directory -- but if you're doing that, it still makes more sense for the auto-generated script to have all those specific "use ModuleN" statements spelled out programmatically at the top. Why not?