As for the limit of players, Kryonet won't be the bottleneck factor. The limit is caused by a combination of factors, such as the hardware specifications and requirements, amount of data that needs to be transferred, connection speed and of course netcode quality. If your netcode is written poorly, then it's asking for trouble and you won't have a very high limit. Besides, a limit can be a bit subjective. I'm sure there won't be a 1000 players at the same area at any given instance. The players will be scattered around the map, doing their own thing. Someone at the very east of the map won't affect anyone at the far west of the map, and vice versa.
If you seperate different areas and instance them on different pieces of hardware, the performance will increase. Only the parts that need to communicate with eachother do so. It's very important to only send information that someone needs, the rest will be a waste of bandwidth and processing power.
The id problem shouldn't be very hard to solve. Instead of the ids being the index of the actors, keep a list of ids and create actors accordingly. That way makes sure that when you remove a player/id, the whole thing doesn't mix up and collapse. Like you said, assign the connection id to the connected player and keep it in a list.