Don't use HMAC, but, sure: iterate SHA1 a couple thousand times. This is the approach taken by PBKDF.
A better approach is to use bcrypt or scrypt. It's not a security objective of SHA1 or HMAC-SHA1 to take a long time to run --- in fact, they have the opposite design goal. Bcrypt and scrypt have both been designed to be "cryptographically slow": speeding them up in the general case would (forgive an oversimplification) require a new result in cryptography that would be more significant than "optimizing brute force cracking".
I proposed HMAC just in order to avoid that there is some strange property about H(H(H(H(H(...))) probably not true for SHA1 and many other believed secure hash functions and block cyphers.
Btw another slow thing that can be used is Blowfish, as it has a slow key scheduling stage, but don't know if it's slow enough.
Another approach can be to take any Feistel Network based block cypher and turn it from M rounds to M*N rounds.
There are many ways to turn a secure cryptographic primitive into a monkey asses slow cryptographic primitive that seriously limits the effectiveness of brute force.
Bcrypt is a pessimized version of Blowfish. If you're working at this level of granularity, it should be for a research paper, not something people actually use.
A better approach is to use bcrypt or scrypt. It's not a security objective of SHA1 or HMAC-SHA1 to take a long time to run --- in fact, they have the opposite design goal. Bcrypt and scrypt have both been designed to be "cryptographically slow": speeding them up in the general case would (forgive an oversimplification) require a new result in cryptography that would be more significant than "optimizing brute force cracking".