I am the lead developer for the RestKit project and I would recommend that you not use UISpec for your testing. RestKit's use of UISpec (more accurately, a pared down highly customized version of it) is an artifact from early in the development -- I was using UISpec for functional testing and was hesitant to carry around so many libraries. These days UISpec is essentially abandonware and I have moved on to using KIF from Square for my UI/functional testing.
For unit testing on new projects, I like Kiwi (https://github.com/allending/Kiwi) as it sits on top of the built in SenTestingKit and provides RSpec style tests. Cedar (https://github.com/pivotal/cedar) from Pivotal Labs and GHUnit (http://gabriel.github.com/gh-unit/) are solid as well. RestKit itself will likely transition off of UISpec at some point in the near future.
Now, on the question of how to setup the database for your tests. If you look in the RKSpecEnvironment.h/m files in RestKit, there are a bunch of helpful methods for unit testing. Assuming that you are using RestKit's Core Data integration, the RKSpecNewManagedObjectStore() method will tear down the Core Data environment and set you back up with a clear database by deleting the persistent store.
RestKit's own unit tests can provide some good reference (aside from the test harness concerns above) about how to unit against the API data. The RKSpecResponseLoader class is useful for turning asynchronous REST requests into procedural steps (it serves as a delegate for RKObjectLoader and will spin the run loop to wait for a request to load) that you can test against. So the general pattern is to clear the database state, setup any objects you need/expect, then perform an API interaction and assert against the results or new state in Core Data.