Ahem, you're exaggerating there just a little bit. There are probably around a dozen web frameworks that are competing for the spotlight right now. With Zend, CI, Django, Symfony, Struts, Cake, etc. all equally if not more popular it's hard to say Rails has the "bulk" of today's web devs. I wouldn't even go as far as saying that the bulk of today's web devs appreciate MVC.
Some of the Node people like things small but when applications get bigger putting things into an MVC structure often makes your code more organized. Until someone comes up with a better idea that takes off this is how things will be done and I think it's great that Node has a few choices now to do this.
The types of projects that benefit from being in node.js instead of Rails, Django, etc, don't really benefit from having all those decisions made in advance. If the "Rails Way" works for your project, you'll probably benefit from doing it in rails. There's certainly more library support and it's easier to find more experienced developers for Rails than node.js.
There's a tendency to put all kinds of projects in node now, just because it's "hot". Some projects benefit from node, and some would be easier to do in some other language/framework. If you're experienced with Rails and are working on a project that fits that style, you're probably better off just doing it in Rails rather than switching to node and using a Rails flavored framework.
By the project, I presume you mean Rails. Because Rails doesn't force ORM on you. It assumes that by default, but if you don't want to use an RDBMS and ORM, you simply remove the inheritance from ActiveSupport::Base from your model class and write a class that talks to whatever you prefer.
Rails makes the reasonable assumption that most people will be talking to an RDBMS. It could omit that and instead you could "build it out and customize it like you need", but that way lurks 7,000 line XML config files and all the other crap lots of Rails folk were trying to escape from. The point of convention over configuration is that for some baseline assumption of normal, it comes ready to rock and roll.
I'm neither anti-Rails or anti-ORM. But the types of projects that actually benefit from being in node, rather than Rails generally benefit from not being tied to those conventions. If what you're doing fits the Rails pattern, that's probably a better solution than anything in node. If you're doing a project that doesn't fit that, and you need lots of customization, you're probably better off doing that from scratch (or with a minimal un-opinionated framework).
I think both have their places. It really depends on the project.