Rory - Unit testing and performance testing are two different things. For perf testing, yes you should restore the database but NUnit or any other unit testing tool is not the right tool for it. I think you are in the right track with your method of rolling back. Unit tests and scalability test/performance tests are two different things.
When you talk about database testing performance and scalability issues you have to deal with blowing up database and running (some staff you can test only on the production environment though). You have to deal with index tuning, transaction log handling, etc. BTW, there is no need to restore the database just attach/detach (take offline/bring online). IMHO rollbacks are not suitable here, they do change runtime behaviour. Besides, you measure performance mostly on selects and not DML when you deal with databases.
Yup, I commented on this in your original blog about this. As our number of tests went up, the time it takes to run the tests got to the point where developers were no longer running all the tests. Using transactions to rollback as a techniques was the first thing to go as it added enomous amounts of time to the run.
Currently, I am working on having my dal support mock objects directly, so support the idea that the details of how a class accesses data shouldn't be exposed on thier interfaces, but instead the dal can be manipulated by the test code to use mocks while in the test environment. In that way, I can support test data in files, mock data written in code, very small test databases that can be restored quickly, and substituting faster test optimized queries to get expected results.