Agree with Andy here and think you need to take great care ensuring that the test reflects what may actually happen.
First I'd look at session timeout and memory release. Ensure that your first batch of users remain active preferably doing something useful say every 30 seconds. This will ensure no session timeouts and also give you some measurable responses.
Then log on further users and as Andy says look at the initial users response times and the new users log on times, and see if there is any deterioration . If there is then check if there is memory available, any shortage of cpu, and any excessive system activity related to managing the large number of users.
You should look at how much cpu is used for actual user work and how much for system overhead (not always as easy as it sounds).
I have seen live systems lose part of their concurrent users due to sub network failure. The users when the network comes up try to log on again. It is interesting to note if they find their previous sessions (assuming these have not been mopped up). And of course how long the now orphaned sessions last.
I haven't used it but from the documentation the Ultimate Thread Group in jmeter should allow you to set up a realistic test. But do allow sufficient time for the workload to stabilise before firing the second batch.