GameMaker could be a viable option, yes. LibGDX is another good cross-platform system that plays well on iOS, Android, Web, and PC.
As for the online servers, the confusion between "persistent worlds" and "MMO" is something new to the last few years of game players. There are three basic tiers:
* A few players connect for a session, play a game, and are done. Worlds can persist or not, matches can be random or not. "Online game."
* Hundreds of people playing together at once, infrastructure is a very small number of servers. Various names: graphical MUD, web games, occasionally "massive online", online games, etc.
* Typically millions of players (although many hundred thousand players can also fit). Infrastructure is generally multiple data centers around the globe. "MMO".
The small online games are relatively easy to build and nearly free to maintain. Players can often host a server directly on the same machine they play the game. This style often includes the 10-minute game sessions of FPS and some simpler RTS games. They can be persistent worlds; MUDs were the first example of online games in the 1970s and they were persistent. Minecraft servers fit comfortably fit in the first category. You can get away with minimal network planning on some designs, others require significant effort. This is the type that the network forum has examples of a fully-functional online game server in a few hours.
The medium and large scale online games are harder to build and usually have a larger team set up for server development. Servers usually require multiple programming disciplines to create, and usually the game clients have multiple network-centric developers. Servers are generally plural and are designed to be dedicated machines. Expect to pay tens of thousands per month for servers, staff, and bandwidth. These can include all types of games, from the 10-minute sessions to global lobbies and matchmaking to very large dedicated worlds with small numbers of players. These require significant effort and planning for network infrastructure.
Then MMO. MMOs are huge. EVERYTHING is designed around networking. Gameplay is designed completely around networking. Animations are designed around keeping things mostly in sync on networks. Data management is designed around getting necessary information across the network while limiting information to prevent cheating over the network. Expect to pay several hundred thousand or into the millions for monthly server maintenance and bandwidth. If one day of development goes by and somebody didn't think about networking at all, that person probably should be kicked off the team. Questions about latency and bandwidth should be part of nearly every meeting.
Within the small class you can turn a small chat system into a simple space shooter or a simple persistent world or a simple social game fairly easily. I've built and shipped games on devices from the DS to the X360 and PS3 that relied on this kind of very simple message passing. If your engine provides central hubs where all events and data are processed it might only take a few weeks for an experienced network programmer to add a networking component. If your engine has scattered processing where everything updates itself, adding networking can mean major changes to everything.
If you have a system designed to support several thousand concurrent users you can morph it into a different but similar-scale system with a bit of work. Transitioning from a moderate sized RPG to a different RPG is much easier than transitioning from RPG to RTS.
If you have a MMO and want to make a similar MMO, the client and server rework can be extensive. If you are moving from an RPG to a similar RPG you might end up with anything from a small number of scripting differences to a huge number of component differences, in the ten to fifty work-year range. If you are switching between styles, say from an MMORPG to an MMOFPS, be prepared to spend several hundred work-years in the transition. It may sound like a lot, but considering the game probably would require thousands of work-years to complete the cost is relatively cheap.
From what you described, you probably fit in the first category. Again, make a few single-machine games first, but when you have done that it is pretty natural to experiment with the first category of online games. I would start by adding a simple and reliable chat to your single-player game, then add components one feature at a time. It is as simple as adding a side-channel to the chat system where the relevant details are shared.