Specifying maxPoolSize in Node causes that number of connections to be established immediately upon first connect (no actual database operations are required) which may include authenticating all of them. The "connect" call does not trigger the callback until all maxPoolSize connections have been established. If any one of these fails, the entire connect call fails.

From the server POV, specifying a maxPoolSize of 200:

(198 connections removed)
...
2015-07-03T11:29:51.845+1000 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:51209 #202 (199 connections now open)
2015-07-03T11:29:51.846+1000 I NETWORK  [initandlisten] connection accepted from 127.0.0.1:51200 #203 (200 connections now open)

And since auth was enabled, this was followed by nearly 10 seconds of authenticating:

(198 auths removed)
...
2015-07-03T11:29:59.476+1000 I ACCESS   [conn203] Successfully authenticated as principal admin on admin
2015-07-03T11:29:59.476+1000 I ACCESS   [conn202] Successfully authenticated as principal admin on admin

Node test client console log I think is self explanatory:

URI: mongodb://admin:password@localhost:27017/admin?maxPoolSize=200
connect @ Fri Jul 03 2015 11:29:50 GMT+1000 (AUS Eastern Standard Time)
cb_connected @ Fri Jul 03 2015 11:30:00 GMT+1000 (AUS Eastern Standard Time)

This can have interesting side-effects; if the pool is large (500 is not uncommon) and a mongos is in use in close proximity, then the connections will be received in a very short space of time - in my tests, I found that a pool size of 600 nearly always failed to connect when the mongod/mongos was co-located - the error was ECONNREFUSED. This error occurs when the receiver is unable to process the incoming connection requests fast enough to maintain empty socket accept buffers. With a pool size of 1000 I never managed to connect at all. With a remote located server the problem went away - presumably because the network itself introduced just enough latency to allow the server to keep up.