I can see why it's confusing. Normally, getPage is sending that information to itself, so it seems odd to send the information yourself.
To expand on what Susan said, you might think of it this way (I haven't looked at the getPage code in a while, so I'm partially making this up -- but I think it's close enough to explain the process):
Normally, when you request a page with a getPage tag on it, the getPage snippet runs and displays a particular page of data (usually, some collection of abbreviated resources). It also creates "links" to the next and previous pages. Those links contain $_GET parameters that getPage has calculated to tell the receiving page (getList again) where to start and how many items to get. When you click on one of those links, it's kind of like submitting a form. It looks like you're going to another page, but you're actually just reloading the same page, but with new parameters which are interpreted by the getPage snippet to show different data.
What you want to do is simulate that with Ajax. Basically, the previous and next buttons, rather than being href links, would launch some JavaScript code in the browser. That code would issue an Ajax request to the page with the getPage snippet on it -- sending the same parameters that getPage would have sent to itself if operating normally.
All that said, I'm not sure I see why you want to do it this way. The usual use of JavaScript in this situation is to avoid reloading the page, but every Ajax request is going to do just that if you want to use getPage to display the data. And if the JavaScript code that issues the Ajax requests is going to have to calculate and keep track of the limit and offset, why use getPage (the main purpose of which is to do the same thing)?
I think I would use either getPage or Ajax, but not both.
If you think about it, many of the manager pages already do exactly what you're talking about. The System Settings grid, for example, lets you navigate forward and back through pages of System Settings. They could just as well be Resources instead of System Settings. Site -> Search is a better example, it actually lets you navigate through a selected set of resources, showing a page at a time, with forward and back buttons.
One way to go, as Susan suggests, would be to have the JavaScript keep track of the limit and offset and send an Ajax request to a page with a getResources snippet that used the parameters to create a page to display.
Another way (how it's done in the Manager pages) is to have a getList processor like the ones used in the Manager that gets *all* the selected resources and returns the desired fields from them as a JSON object. The JavaScript would take the data from the Ajax response, figure out which records belonged to the current page, and display just those records (along with next and previous links when appropriate).
I hate to even bring it up, but ExtJs/modExt does this all automatically if you don't mind having the display in a grid (which in theory, you could style to look any way you want). All you do is set up the Ext grid in JavaScript (specifying the URL of the getList processor). I think you could actually use the existing Resource getList processor to retrieve the resources.
The number of different ways you can do something in MODX is both a curse and a blessing. I hope I haven't made you even more confused.