No it doesn't. It can skip verifying very deeply burred signatures (as is the checkpoint behaviour), since with headers first it knows the amount of work on top of them and can perform the tests only probabilistically past a certain point.
Is this planned for the reference client (along with fraud proofs, presumably)?
Pieter and I-- at least-- have been talking about it for a while as part of the motivation for headers first, even prior to the fraud proofs: past some limit (E.g. max(60days work at the highest difficulty ever observed in the best chain, 2016 blocks) ) a huge reorganization at tip is a guaranteed system failure. (Once you cross 100 blocks a reorg starts forever invalidating an exponentially expanding cone of transactions). For a while this wasn't as interesting because the total time to replace the chain with the tips hashrate was very low, but it's finally expanding nicely:
http://bitcoin.sipa.be/powdays-50k.pngAnother potential softer safety mechanism is simply holding the confirmation count in the RPC at zero when there has been a 'system failure grade' reorganization to allow time for a "higher process" to sort out the mess. This also needs a couple other pieces to be completely useful, like the ability to manually invalidate a block over the RPC.
First priority was getting headers first in, tested, and mature.
Obviously fraud proofs have been on my mind for a long time, but they have a lot of protocol surface area. The recent reorganizations of Bitcoin core (e.g. libscript work) will make it easier to work on them with confidence, e.g. be able to build an external process that receives and checks fraud proofs.
