I've never done a virtual world, but where a project like this would start for me is designing the world roughly (on paper). What happens when a client connects, what happens when the client disconnects/drops suddenly, what data is persistent and so on. Then designing how the clients communicate with the server and with each other (ie. the protocol). Presumably if you are planning on using RED5 this would be a centralised thing not a P2P one. Once you have the protocol designed on paper you can code it up and see what you've missed -> iteration number 2. Depending on how much experience you have on stuff like this you'll need to do 2-10 iterations of the communications.
For the design state I would look at game engines and see what they provide in terms of distributed play. I'd imagine that you'll want to use a game engine to render the stuff so you'll need one anyway.
If you've never done stuff like this before, it might be worthwhile to make a little game just to see what are the things you need to take into account. Like a multiplayer pong for instance. Although the realtime constraints on pong are slightly different to those of a virtual world (at least if there is no one driving around at 200 km/h in the world).