You're going to have trouble beating ejabberd on its native turf, and JS probably isn't going to let you beat its memory usage anytime soon, based on what I've seen in my running servers. ejabberd is considered a memory hog of an XMPP server, because it might use as much as a kilobyte for a connection's state information, vs C or Java which can go smaller due to full control over the memory. About 200 bytes is more common, though. JS would leave you with even less control over the memory and make it very easy to go ever further over 1KB/connection.

And actually, having experienced ejabberd and worked with its internals quite a lot professionally (for about two years), this is where I think Node.js would just fall down screaming. A serious XMPP server ends up having to do some actual logic that can take some actual time, like working out who is on the roster, which takes time when that may be a couple hundred people. It may still be a fraction of a second, but Node.js is either going to choke and die on the sheer overwhelming number of small little things that still have to be done synchronously, or the XMPP server would have to be manually sliced into tiny, tiny ribbons (instead of working out the roster, working out the next roster item and pushing it out) in which case call overhead would still be a problem too. And being stuck on one core is going to be really rough as you try to scale.

You aren't going to get what the XMPP world would consider "low memory usage" out of Node.js, and "non-blocking" will only get you to toy size. Which may be enough for some tasks since "toy size" is still at least tens of users before you really start hitting these problems, but based on my experience even at the medium hundreds level you're going to start hitting problems.

(The steady-state of an IM server isn't too bad and if we just assume Node.js has somehow made it to the steady state it could support several hundreds relatively easily. The problem is that a real-world IM server ends up getting these spikes that you might not anticipate if you've never worked with them, because events like going online and offline are not independent, and these spikes are what will bring your server to its knees. In particular, there's the case where your IM server itself lost its network connection, then it comes back, and all the clients try to reconnect at once, hammering your server with the full login process for every connected user, full presence storms, complete reconnection of every S2S connection, every transport user reconnecting, basically everything happening all at once, and this is an enormous number of things to be stuck doing synchronously per-item. You will experience the full hell that can be brought to you by cooperative multitasking. The best part is, if your server can't take that process and actually goes down, when it comes back up it gets to start all over again, probably just to crash again. To have a working IM server takes more than being able to handle the steady state, if you can't deal with these spikes your server will have trouble just getting to the steady state. There are some other spikes you can get, too. Also, you'd be surprised at how quickly users pick up on the fact that your instant messages are actually taking 2 seconds to send.)