Yes, typically, you will have a set of entities that are visible, per viewer. This ends up being n-squared memory/pointers to manage, which is in fact one of the things that end up limiting the scalability of MMOs from being just purely linear. (Although the game design of trying to draw 1000 players in the same screenful location is more of a challenge, on modern hardware that could otherwise keep up…)

A straightforward algorithm is to run, for each player, a spatial query against their viewing radius, and update each entity that is within the viewing radius with a “last seen at tick X.” There, in turn, you probably use a double index structure, where you have a hash table from entity ID to viewed-entity record, AND you have a heap/priority queue (or maybe just a set of buckets) which tells you when an entity was last seen. When an entity is seen in the query, and is not found as currently visible when you try to look it up in the hash table, you know that this is a “newly visible” entity, and can schedule the static data for sending.

You'll typically also walk the list of all entities visible to a player, and send updates about them, perhaps on some schedule. And when you do this, you can detect entities that have not been within visibility range for some time, and schedule a message for “this entity is no longer visible.” Depending on how you implement reliable state replication, you may still need to hang on to the entity visibility record until the other end acknowledges the packet that contains the “not visible” message, though, so that you can re-send it if the message gets lost. If you use TCP, then that's obviously less important, but then you instead have to live with TCP withholding newer information from the recipient while it's waiting for retransmission of older data. There are many ways to skin that cat.