Amusing as it is to see my real name (Chuck) used like this, I think the word you're looking for is "chunk".
Tho if I don't lay off the beer and curries, I'll certainly be deserving of the latter name too
The answer is, when a player enters a chunk, you load enough surrounding chunks to cover the entire view distance plus one extra chunk (so the horizon doesn't appear in choppy fashion). In fact, you'll probably want even more chunks in memory than what's visible so you can still run the simulation in them, though you can fudge things a bit if you can prove no one can see what's happening.
As for keeping the current chunk updated for each player, since you always have to know exactly where in the world every player is, knowing what chunk they're in should be a trivial matter of dividing their coordinates by the size of the chunk.
Once you've generated a chunk, don't think of it as "loading" or "saving" it -- they all exist, just that some might have to be moved from disk to memory or back. Thinking of it that way, it's just more of an optimization problem than a show-stopping design problem. Don't be afraid to just throw every chunk in RAM to start out while you're developing -- as long as you keep some notion of discrete chunks, it'll be simple to offload them to disk or stream them over the network later.
Oh, and don't use UDP unless you're fine with dropping packets. If you find yourself retransmitting them, you're already well on your way to poorly reinventing TCP.