Note: This answer was written for an earlier version of the question which lacked any details about what the project was actually about.
While it does not answer the new version of the question properly, I will leave it up, as it might help others.
I’m sorry, but you can’t do such an estimate without having a prototype. Not every MMORPG is the same. Depending on various implementation details and your game mechanics, your bandwidth can differ a lot.
For example, how often are you going to send position updates to the clients? When you have an action-oriented combat system where players are expected to act and react quickly, you ideally want to send 100 updates per second for maximum precision. But if the combat system is a bit slower, then perhaps just 10 updates per second and letting the clients interpolate between them are OK. In a very slow-paced system, you might even get away with just 1 update per second.
So this simple design choice about how your combat system works can affect your bandwidth requirements by factor 100. And that was just one feature. MMORPGs are very complex games. There are lots and lots of features which could require a lot of bandwidth depending on what you want them to do and how you implement them.
Further, that number might not scale linearly with the number of players. It in fact usually increases quadratically with the number of players in the same area. When there are 10 players, then you need to update 10 clients each about what happens to 10 different players. Which means you don’t need to send 10 times but 100 times the data. So depending on how the players in your game will distribute themselves around your game world, you might have very different traffic requirements. Sure, there are ways to influence that. And there are workarounds for too many people being in the same area and bogging down the server (like instancing). But do you want to use them? And if you do, when and how exactly? These are all very complex design questions you might not be able to answer yet.
However, you could take a different approach. Set a budget for how much bandwidth the game is allowed to consume. Then take that budget into account while you develop your game. When some feature of the game breaks the bandwidth budget, either drop or redesign it.
But if it turns out that your budget was too low, then a lot of features you considered essential to the vision of your game might end up getting cut. So this approach could lead to frustration for you and your investors.
So you need some experience to judge how much bandwidth you will need in order to make those essential core features possible. One way to gain that experience is by creating a prototype.