Kevin, I’m glad you posted because I think you’re the reality check that I may need
I really don't mean to be discouraging. In fact, I think the only way to learn how to program is by, well, programming! So you're already off to a good start, just because you're trying something.
That being said, underestimating the scale of a project is a mistake that novices (and non-novices!) make all the time. After all, what does the first M in MMORPG stand for? :p
When I first registered and asked for some advice in regards to an mmorpg, I was told that I could focus on making a single player model of the mmorpg game that I am aiming to build. Furthermore I could plan for network and scaling later after I get a good foundation of player, monster, and environment. Is this a poor approach? My overall goal is to detect player vs environment collisions via tiles, and player vs monster collisions via the objects themselves.
In general, my advice is always: start smaller. Break your problem down into multiple individual steps. Break those individual steps down even further. Create prototypes that explore one aspect of your larger goal. Create a single-player game to help you figure out how Box2D works, or how it scales. Create a separate non-graphical game that explores how networking works. Keep these "games" as simple as possible. When you get each one working separately, then (and only then) think about combining what you've learned into one bigger piece.
So, sure, you should focus on the basic collision detection and whatnot first, especially if you haven't finished a game before. But I would argue that it's a waste of time and energy to try to make decisions now, at the prototype level, that will affect your big end goal.
By that I mean: you should start by making Mario. Explore how collision works in a game like that. Don't worry about whether what you're doing will scale or not, or how networking will affect it. Create a small game that uses Box2D. Start over and recreate that same game using basic tile collision. Boom: now you know how to use both.
Then start over again and create a networked chat application. Build from these small steps towards an end goal, but don't try to make decisions about your end goal until you can pretty much answer the questions yourself.
It's a bit like this: let's say I don't know how to build houses. I don't even know how to build a tree house. I have no idea how to create a roof that won't leak, let alone how plumbing or electricity works. And now I ask you: I'm planning on building a castle, so which type of wood should I use for the drawbridge?
The answer to that question is that I shouldn't be asking that question yet. I need to practice by maybe building a fort first. When I figure that part out, maybe I should move up to a treehouse. Maybe I should separately build a little moat and see what types of bridges work best, without even worrying about the castle that will be inside that moat.
I'm not sure if that metaphor works, haha.
Could you elaborate on why Box2D would not be the best approach for handling collisions?
Box2D might be a fine option. It's a great option for a single-player physics game. Is it the best option for a non-physics game that can just use simpler tile-based collision detection (like Mario)? Probably not, only because it's overkill. Is it the best option for a game that handles collision detection on the server? Maybe, but your entire setup will look completely different, and what you define as "efficient" might mean something else.
My real point is that we can't really answer the question for you. It depends more on your personal preferences and coding style, and more on the exact type of game you're building (which even you probably don't exactly know yet), more than it does cold hard technical facts. The only way to get a more concrete answer is by building small prototypes that test out different theories.
I’m starting to get the feeling that I have started programming from the incorrect approach. I have handled nothing in terms of client vs server and only have a single player instance of a game that I would eventually like to make open to other players once things look a little ‘nicer’.
I wouldn't say that you've got an incorrect approach, just maybe an overly optimistic plan. Think about it this way: you're working on a single-player prototype right now, not your final goal of an MMORPG. That final goal comes later, after you've built up some knowledge about how these individual pieces (collision detection, networking, etc) work.
Alternatively would you be able to point me to reading material that you think may be helpful for a person in my position?
The best advice I can give you is always: start smaller. Instead of asking about how efficient Box2D is for an MMORPG (which we can't really answer, because that question is extremely broad), build a small prototype that tells you more about how many entities Box2D can handle, what types of information it gives you, etc. Then do the same thing with tile-based collision. Repeat until you can start combining these fuzzy concept into a more cohesive whole.
And if that sounds tedious, well, welcome to programming!
Edit: I am reminded of this: http://yourgameideaistoobig.com/
(Again, I'm not trying to be discouraging! We all tend to bite off more than we should be chewing- that's part of the fun of being a programmer! But the only way to get to our big end goals is by starting smaller and working our way towards them.)