No it's not useful to use slow hashing in such a situation.
The relevant attacks against the hash in a digital signature are second pre-images and sometimes collisions. Assuming the hash-function is secure, then there is no way to find collisions with less work than $2^{n/2}$, and second pre-images with less work than $2^{n}$. There is no weak part the attacker can abuse in his attack, so he needs to face the full strength of the cryptographic hash.
As long as the algorithm remains unbroken, we can make the problem exponentially difficult for the attacker, while increasing the cost only linearly(or something similarly low) for the defender. In short we don't fear high computational power, we only fear crypto-analysis.
With password hashing, the relevant attack is a first pre-image. The problem here is that typical passwords have a low entropy, i.e. they're easy to guess. When guessing the original password the attacker doesn't care how strong the hash-function is, he simply executes it with many different inputs. We use slow hashes here, to increase the effective strength of the password by perhaps 20 or 30 bits.
There is no way to slow down the attacker exponentially while slowing down the defender only by a little bit. That's because the attacker has the same knowledge as the password verifier, and does exactly the same thing as the verifier. Any slowdown hits the defender just as much as the attacker.
The only thing we can try is to minimize the advantage an attacker gets from specialized hardware, and make the hashing as slow as the defender can afford. This is a desperate measure that's only used because no good defense is available.
