A backend for Meteor, fronted in another language doesn't exist. What I'll assume you're looking for is a bridge. Which Meteor.JS provides access to via the Distributed Data Protocol (DDP). There are clients for most languages, from javascript to ruby and etc. However, there are no servers operating the DDP outside of Meteor to the best of my knowledge. The DDP itself is kind of like REST over sockets on steroids.
I worded it as an oversimplification, but it does offer the same service a REST endpoint would offer (CRUD docs), and more via subscriptions. REST in itself is just an RPC, what I'm trying to convey is that it offers the same, plus more over a socket.
Those are the best solutions, at hand that would work well with Rails.
I wouldn't advise smashing a Rails app and a Meteor app together unless you have a solid case to do so (like migrating).
Rails, aside, I'm happy to here oplog has landed. 1.0 feels imminent, the tension is growing, even here in Toronto. Stop waiting sheeple, Meteor is great as is, and it's only getting better.
I guess it all depends on how "deeply" realtime your app needs to be.
For example, if you just want to add chat between users I think you'd be well-served by Firebase for the chat. If you want to roll-your-own, there are a million Node.js chat tutorials.
However, if you'll be making important changes to "real" data, as in anything you're persisting with ActiveRecord, b is your best bet.
meteor.js is really cool, but it is not ready for production, so it depends on how important your app is. Scaling it beyond a single server is actually not that simple.
Another factor to look at is how extensive the realtime functionality will be. If you just want to make a realtime dashboard for your app, using ajax with a partial to redraw a div every second (or do nothing if the ajax returns no change) is really simple compared to having to add the complexity of another service in a different language (remember that node.js will run on a different port and as a separate process from rails).
If your app is highly dependent on realtime, and you're not planning on launching to a wide audience in 6 months, sure, rewrite in meteor.
If you already have a database and just need to send stuff to the page, you can set up Faye or Pushpin alongside your app without having to rewrite anything.
If you like SaaS realtime, in addition to Firebase there's also PubNub and Fanout.io.
Can Event Machine or Celluloid give me reactive updates from my database made by a different process or service (like some background task with message queue)? Or are you bringing those as alternatives to EventEmitter of node.js?
My point is: neither Event Reactor nor Actor model implementation are sufficient to make your database realtime (push updates to the application server). And the amount of work that was put into MongoDB actually doing it correctly and reliably is very undervalued in this thread.
That's why there are so few "real-time" solutions built around databases (NoSQL or SQL): Meteor, Firebase, GoInstant.
Always keeping everything in memory and updating clients as soon as the server have gotten a write is a different story with different complexity and different scaling limits. (but it can be done more efficiently utilizing RAM servers like Redis; Redis has built-in notification interface).
