It's quite easy, and you still get reactivity. You publish the collection as before, but you write a server-side filter (a well-documented core feature) that only sends a small piece of that to the client. Even though the client only sends a small piece, the changes to those items are still reflected back to the server and other clients live.
It's supported this from the day it was released - I remember hooking up something quite similar at the time. It was never purely autopublish.
In addition to that to make robust pagination you need aggregation. Printing the message "you are looking at page X of Y pages" requires you to know the count of the collection or else you can't say how many pages there are. I.e You need to reactively monitor MongoDB's equivalent of "select count(*) from blaha". Doing that (without cheating and caching the count) is very expensive in Meteor.
One count(*) query per request is not expensive at all. Suppose you cache the count and someone else adds rows to the collection. Your cached count is not getting updated and the whole reactivity concept breaks down since your app now thinks the row count is different from what it really is.
It's supported this from the day it was released - I remember hooking up something quite similar at the time. It was never purely autopublish.