Define millions of players "on at the same time".. you can definitely plop a million people on the same space even with basic web technology.. look at some not games but collaborative drawing tools which allow users to draw onto a common whiteboard.. A simple system where the server just queues up commands, draws on the whiteboard and then replicated the final image to all users.. Though not a game, it's much the same with games. Web services can scale up to million of users no prob, that's not a big deal anymore and DB can handle the load etc.

The issue with games is there are both client side and server side limitations, but mostly client side. You can't render a million objects in most game engines at acceptable framerates even on the low settings on most PC and forget about it on last gen consoles.. so there was never a desire to make a 1 million user game, but if someone was going to make one, the server side wouldn't be the limiting factor.. We already have web services which host 1 million concurrent users near realtime already. If someone wanted to do this you can use lots of novel algorithms to handle the server load and synchronization.. On client side u will need a custom 3D engine designed for 1 million object system..

but still connect each player to each server,

That is not the case. Some players will be connected to some servers. Players will defiantly not have the entire state at once. Players will only have a subset of the world: their current viewport at their current zoom level. Zoomed out views will interact differently than zoomed in ones. Looking at england you will not have all the info and options as zooming into london. I am thinking that if the mechanics are simple enough I can employ some creative "dead reckoning" asynchronously: the server will only communicate once every couple of seconds, but the game will still appear realtime.

handing off players between server 'areas' and interactions across the

I am thinking of dynamically subdividing areas between servers instead of dynamically dividing the players. If an area becomes too complex, it can be split in real time between two machines. A player might be connected to several servers. The real "fun" here is managing the boundaries.

I plan to allow this through very simple game rules as in "curiosity": instead of a few complex interactions I want many simple interactions. This will make the game very abstract (casual), but it might enable me to persist a huge real time world.

The other answers say why this combination wont work (effectively YOU WILL be dynamicly dividing players if you break areas into smaller areas assigned to additional servers.

But still keep the dynamic server area idea in mind -- shifting area boundries and shifting/splitting (and joining again) to load level the servers, if players are free moving (assuming complicated enough interactions and bookkeeping for objects in the areas) and also that each client may get feeds from several servers whose areas they are adjacent to (and their Range of interaction crosses their boundry).

If you have NPC objects which interact across the area boundries, interactions between them is needed also.

You can often optimize by 'ghosting' a buffer area outside an areas boundry (maintained locally in a server, and fed from the adjacent servers for that sub-area) so that information is marshalled to cut down on object update data transfers (processing can find position/event data locally instead of having to call across to another Server).