Technically, HMAC is a MAC, not a signature. Some people get the terminology wrong (in particular Microsoft's documentation) and call HMAC a signature, but things are clearer if you use the right words.
HMAC, when used with a secure hash function (say, SHA-256, but SHA-1 is fine too), is resistant to forgeries; that is, the attacker cannot succeed in computing a valid pair (m,h) where h is the correct HMAC value for message m, even if the attacker has access to many pairs (m',h') (where all m' are distinct from m). In particular, the attacker cannot guess the HMAC key, because obtaining the HMAC key would allow him to create a lot of forgeries.
Salts, and PBKDF2, make sense only if you envision that exhaustive search on the key might work. Salting and slow hashing (PBKDF2 does both) are mitigation measures to make life harder for the attacker in that case. In your scenario, the HMAC key is "strong", i.e. immune to exhaustive search (e.g. it is a sequence of 128 bits obtained from a cryptographically strong random source). Therefore, salts, PBKDF2 or other ritualistic elements won't make it any more secure. HMAC is already fine as it is.
Note that in the case of cookies, several users may collude and exchange their HMACed cookie values. A user could also record a cookie value, and send it back to you afterwards, even if the server sent him a newer cookie value. Depending on your usage context, this may or may not be a problem.