Of course, the more code you have in the application, the more memory it requires to load all that code when running the application. But
In other words, are memory concerns a good reason to split generated code such as entity framework into N DLL's?
I would say no. Modern day computer should have more that enough memory to load all the executable code at once. There could be an issue with run-time memory, e.g. if you were to try to cache all the data for an enterprise application in memory. But not the executable code, IMHO.
And splitting it up into several DLLs would not help a lot. You would still require to load all the executable code in order for the application to work. Except if you would load/unload code on demand.
And trying to load/unload code on demand does add extra complexity to the project. This complexity adds cost and risk (which is more cost). E.g. you cannot simply unload a dll in .NET. You have to load it into a separate AppDomain. Then you can unload the AppDomain.
If you really was hitting the memory limit for executable code, upgrading the memory on the computers running the application would most probably be cheaper than implementing loading/unloading of code at runtime.