This question is making my head hurt, but I'll try to help you out.
I do not know what limitations either of the games you mention have. I'm hoping you can take this info and fill in the blanks.
First we can look at database size. We need to take the maximum size of the gaming world and make it persistent in a database.
If the game board is made up of cells that have a biome/type, that could be an enumerated type or a short int/cell. If the board is 1 000 X 1 000 cells, that's one million short int's. If there is a capacity associated, that could be another int/cell. Keep adding until you think you've gotten all the information per cell accounted for.
Next we count towns. Towns usually have buildings in them, we can again make that an enumeration, so we'll call that another short int/building space. If each town has a 10 X 10 building space, that's 100 short int's per town + the town name + an int identifying the owning player. Again, if there are other important pieces of data, such as a capacity per building or a building time, that's more space yet. How many towns will there be on the board? 1 every ~10 cells? That's 10 million short int's just for the building types. Again, keep adding until your game is a game.
How many players will there be? and what information will you keep per player? (You can see this is starting to become wildly speculative based on how you program it) From memory I remember Travian kept user logins separate from the game data so a user could be active in more than one game at a time, however there was a lot of in-game player information to keep track of. Guild membership, messages to and from other players, army information, science progress? etc.
Assuming we're using MySQL for the database we can check out the size requirements here
Crunch the numbers and see what they come out as... 20MB? we can afford more than that, let's make the board bigger. 500GB? way too big, let's remove a couple extraneous bits of information per cell...
Next we can look at the bandwidth use. This has a lot more to do with the way you program your game, and so will be more speculative than the above size estimate. You need to estimate how many players you will have, how often they will be making web requests, and how much data you will be transmitting per request. Are you giving them the ability to see the whole board at once? Then you'll be transmitting all of the board data each request, so you probably don't want to do that. You want to give the user exactly the information that will show up on their screen at any moment and no more. Use the above estimation methods to total the data that will be required to set up one screen-shot from your game, and consider that the minimum of what you will have to transfer per request.
Assuming that you go to the effort of transmitting the data in some sort of binary format, you can probably estimate the byte-sizes with the SQL sizes above. If you transmit the information in JSON or XML, you can start counting one byte per digit in each of the numbers.
Again, tot the numbers and see where we're at. 1 MB per month? no problem. 1 MB per second? maybe we should start restricting user's request rates...
I think I'll stop here and hope you get the picture. It should be evident that without some kind of design information (preferably source code and database schematics) we can't really say what size restrictions a game will meet. I hope you can also see that depending on game design and coding, these things can be scaled to meet any reasonable size restrictions we put on them.
In the end, I would say that size is really so low on the worry-list that it's basically a non-issue. Go make a game and once it works and is coded to a good standard, then you can check to see how much it'll cost to host and scale it accordingly.
