Instead of doing a full blown MMO, I'd look at maybe only taking control and hosting player data and possibly lobbies, while letting users host their own worlds so you can avoid legal issues with user generated content. You could even let players have portals in between their worlds so the game seems massive. I'm working on a fully dynamic game like this at the moment but with no multiplayer yet. If I do add multiplayer I will probably do what I said above. If you don't want to get sued I'd suggest doing the same. As for the problem of getting the deformed content to the user... what I'd do is download all dynamic data on the first time playing then just keep changes in a buffer for each client then stream the ones the player is closest to first and then the rest. You'd also have to keep an offline change buffer for each player. And again, just stream the closest ones when the player logs in and all the rest whenever you need to.
Im not doing it myself, Im more trying to convince game companies to improve MMORPs in the ways Ive mentioned (the current crop havent significantly changed from 10 year old methods and in many cases move backwards)
There is a game called Neverwinter Nights that had(has) a similar model to yours with a actual server (I played around with it many years ago. They supported upto 64 players per server (effective was more like 30) and they did have players do portals between multiple serever to extend their capacities and world size.
They actually used a 'chunk' system with precanned terrain modules (few parameters on the modules, but they did allow placeables and the usual triggers and spawns and NPCs with dialog trees/questgiving). People published their 'world' sets but most were truely lame and only a few seemed to put the thousands of hours of development needed to create good interesting/cohesive ones and THEN they also had to moderate their servers.
They also did have player created/modifies assets that added alot to the game (more terrain modules, lots of clothing, placeables, NPC/monsters figures and such - animations?) and distributeable serverside scripting (ex - a substitute scripted battle AI for monster opponents alot better than the company supplied one was ). They did at that time supply at least twice large asset set patches/replacements (which you had to have to run world created using those extended assets sets).
They had some halfway good tools to build worlds (out of the terrain modules plus the usual trigger/spawn placemenst and more) and an interesting NPC dialog tree editor (imbedded animations for the NPC and player attribute adjustments and other activations)
A significant problem was that the game NEVER (as far as I know since I havent looked at it for years) had a Program Interface (DLL or otherwise) to link in native code. It all ran their lame/limited slow scripting language. Players did cleverly reverse engineer some of it and actually added a persistant bank system (saved containers to SQL) triggered by some trap that intercepted in-memory buffers). A program interface would have made server-side processing improvemenst by players much easier and could have used the speed of additional server boxes to run NPC/Monster AI and smart spawning and to cross between server worlds while in-game. It was actually a mystery to me why then hadnt thought of it and never added it when many players were calling for it over the space of several years. Even simple data transfer via TCP routines via routines their script langage library (to allowtie into native C++ processing on a second/additional boxes) which would have been dead simple to do, they never did. (idiocy in my book).
You may want to look at creating a server component to act as a ' world change' clearing house so that individual clients being lost doesnt take the change data with them. Failover server transfer is a typical feature so that if 'the server' machine is lost all the game isnt lost, though recovery still might take half a minute for the primary serverr replacement to sync with all the clients and signal the transfer of 'serverhood'