If i muddle around without planning for such things and when the time comes I have to rework most of my stuff because I was simply throwing things out there, it would be a huge waste of time.
Wouldn't it be an even huger waste of time to spend time writing support for a game that nobody wants to play? Or spending time optimizing something which won't actually turn out to be a bottleneck in the end?
Part of what makes the game fun ( as per what I want to do ) is having 100+ players in a server fighting and going at it.
But that doesn't mean that login servers are a bottleneck at all. A login server needs to verify user name/password, generate a signed ticket with some lifetime, and write an entry into a log file. You can do thousands of that per second on a single virtual instance, and if you have a thousand users per second logging in, you're bigger than any indie game company I know of (except possibly for Steam.)
To ensure that happens I need to make an authentication server that doesnt bug out like minecraft does.
I think Minecraft is a phenomenal success and I would have been very proud have I created it. Sure it can be better, but 99.9% of all projects are actually failures. Usually, the problem is that developers spend way too much time building things that don't matter *yet* instead of making sure they figure out what the successful game will look like. Building robust infrastructure as you need it is much easier than building a compelling experience that users want to pay for.
That being said: If you can spend six hours instead of two hours on some task, and the difference is that with the six hours, you solve a problem right, and with two hours, it will fail when you have a hundred users, then spend the six hours. Just don't spend six days if you can unblock the "fun finding" with two hours of work.
If you want to understand load generation, set up a user database in Redis or something. Spin up an Apache or nginx or Node or something. Write a little PHP script or JavaScript or whatever, where all it does is:
0) decode the user name (email?) and password from the request
1) look up the user record based on the user name / email in Redis
2) hash the provided password with a salt
3) compare the password hash with the hash in the user record
4) if mismatch, return error
5) if match, create a ticket consisting of (username:expirytime:hash(username:expirytime:serversecret)) and return success
Now, your client can present the ticket to any server, and it can verify that the user is who he/she says he/she is by simply verifying the hash (all servers should be configured with the same server secret.)
Now, use "ab" or a similar load testing program, running on another machine or two, to generate load for this service, and see how far it goes.
Note that, if average session time is 1 hour, and average login request service time is 10 ms, then you can serve 360,000 simultaneous online users from a single login server, and I'd be quite surprised if the login mechanism described above couldn't be made to run much faster than that.
And, if you're using a simple key/value store for user records, and a simple signed-ticket service for login/authentication, then you can scale horizontally with very little effort -- use consistent hashing for the storage instances, and any HTTP load balancer for the front end. This is a solved problem, and as long as you have a reasonable path towards the scalability you need, you don't actually need to develop and test it until you actually need it. Time is the most precious resource we have, and using it to address the biggest risk first is, IMO, the best use of it.