That is strange requirement. You are building application which should work on some expected data structures but in the same time you want stored data structuers to be different for each deployment?
It is possible to create multiple versions of SSDL and load MSL, SSDL and CSDL from files instead of resources but if you change table names or column names in SSDL you must also modify MSL because it describes mapping between tables defined in SSDL and entities defined in CSDL. Doing this per client can be a maintenance nightmare because you will have to either use one EDMX per a client (new CSDL per a client as well) or manually modify XML of SSDLs and MSLs. If you use POCOs you don't have to worry about multiple mappings because if your CSDLs use still the same names for entities and columns it will work.
If your modules require tables which don't have to be available in client's database you can simply add a configuration which will hide related functionality (or throw exception if functionality is somehow accidentaly used) but your SSDLs will still have mimic that tables are present. Otherwise you really have to create multiple EDMXs - either by module or by client.
Separating the application into modules has another impact on design. If you use single EDMX you must still ensure that there are no navigation properties among entities which can be broken by installing only some modules => there can't be navigation properties to entities from optional modules. If you create EDMX per a module there can't be cross module navigation properties at all except some shared reused EDMX.
I think that part of your application deployment procedure should be creation of updatable views for your application. This will map unknown schema to expected one so that you would still use single SSDL. I haven't tried it but I hope it should work.
