In my experience, I would suggest you start with a networking layer, right out of the gate. Connecting to a network (and the issues related to it) are worth confronting head on. Since it's a multiplayer game, you're going to want to start facing those issues early (and often).
Further, my recommendation would be to develop your server code, run it locally, and when you're ready, move it to its real location. In other words, rather than think of the server as merely a temporary solution for testing, think of it as the ultimate solution in a temporary location, otherwise you're going to be developing the server code twice.1
If you're running your server on the same computer as your emulator, you can just connect to localhost. Even better is to connect to your IP address (the external one, seen from outside your network), and then set up port forwarding of whatever ports your game communicates over to send the packets to your server computer. With that setup you can still test with a reasonable number of people without raising the ire of your ISP.
As far as where the codebase "lives," my suggestion would be: do NOT include the server code in your client codebase. Advantages include:
It keeps the client smaller. (Which is good, since users don't like bigger downloads)
It keeps the server code away from those who would decompile the client to hack your game.
Nonetheless, there will likely be a need for some classes to be shared between the client and server. That's why I recommend that you DO include the client code in your server codebase. Classes that are common to both the client and server can live on the client side. (Alternatively, you could have three codebases: (1) server; (2) client; and (3) shared, but I don't think that's necessary, since the server having extra code it doesn't need from the client isn't a big deal.)
1For my project, I used KryoNet and can't recommend it enough. It's a very simple, clean, open source client-server solution, written in java.