I agree with the advice quoted in Leftium's answer; design it for networking from the start, because you won't be able to add it later.
The first time I tried to make a multiplayer game (I wasn't even trying to make a single player game!), I figured I would first get the game working and then add networking. Bad idea. I was left with a prototype of a really boring single player game and no clue how to transform that into a multiplayer game. I scrapped it entirely and started over, this time writing multiplayer networking code right from the start. Everything clicked.
I'm sure it's not impossible to start with a one-player game and add multiplayer functionality. If you think it through, plan it correctly and make sure you know your strategy then sure, give it a try. I think it would be an interesting puzzle to work through at the very least. But really make sure you know your plan as to how you're going to add networking.
I think there is a middle ground (though I've never tried it). You could write some dummy classes for networking/multiplayer features, and be diligent in using them as you're writing the single player game. Then later, if you decide to implement multiplayer, just fill in the dummy classes and you'd be most of the way done. This very much approaches the server/client method, but you might be able to get away with less work; after all, a single player game is easier to make than a multiplayer game, so if you're going to write your single player game like a multiplayer game then why not just make it multiplayer?