The performance of your SPDY setup will obviously depend on the implementation of the stack and you should know the processing cost vs. a 'regular' HTTP or HTTPS session, but.. Keep in mind that that the primary point of SPDY is to reduce the latency and overhead of rendering a typical webpage (as seen by your visitors), not to optimize your server-side response time.
More specifically: if you want to benchmark SPDY, siege/ab and friends are not representative. All of these tools generate load against a single URI and hammer it. This is a useful tactic to stress test your server, but it is far from testing the benefits of SPDY. To test SPDY, you want a tool (browser, most likely), which will download the page, and request all the subresources on the page, allowing you to reuse the SPDY connection.
We recently ran some benchmarks using Chrome for Android, and you can see the setup here: https://developers.google.com/speed/articles/spdy-for-mobile
Finally. If you do need a command line client to test SPDY, checkout spdylay. It ships with spdycat
which will allow you to make curl-like requests against your server. It's not a benchmarking tool, but it'll get you started.