Instead of rolling your own, you should use [PBKDF2][1], which does what you try, but right. Alternatively use scrypt or maybe bcrypt, they try to be more expensive on GPUs and custom cracking hardware.

> (this will take about a million times longer compared to the usual method of calling a single hash function)

If you used $n=10^9$, brute force would take a *billion* times as long. However, that would be really slow to use in practice. My mid range Intel CPU can hash ~10 million SHA-256 / s on one core, meaning a couple of minutes for your $n$. A million is more reasonable.

> Does it make sense to store them in the following form instead:?

Your iterated hash has some weaknesses compared to PBKDF2.

* Each iteration [increases the collision rate][2]. If you use a large enough hash function with $\log_2n$ bits of collision resistance to spare, that will not matter in practice, but PBKDF2 avoids it.
* By using HMAC, PBKDF2 benefits from security proofs that show it is [potentially secure][3] (pdf) with some hash functions with which yours is not. Also a theoretical thing unless you use an obsolete/broken hash.

  [1]: https://www.ietf.org/rfc/rfc2898.txt
  [2]: https://crypto.stackexchange.com/questions/959/strength-of-multiple-hash-iterations
  [3]: http://cseweb.ucsd.edu/~mihir/papers/hmac-new.html