As D.W. said, the AES key schedule is not a pseudo-random function by itself, and certainly not more secure than something like PBKDF2 (with a hash function or MAC) or any other pseudorandom function. (There is saying that the key schedule is the weakest part in Rijndael/AES.)
It is meant to be fast, still a bit non-linear (so applications of the individual subkeys in each round don't somehow cancel out each other), and easily implementable (using even the same components as AES itself). In low-memory implementations, one can easily calculate the key schedule again for each encrypted (or decrypted) block on the fly, without really big performance-hits, which certainly wouldn't be possible with something like a big-factor slow hash function.
Note that any modification on AES will not be AES anymore. Using more rounds doesn't even give another Rijndael variant. Rijndael is a larger family of block ciphers with key sizes and block sizes each one of 128, 160, 192, 224 or 256 bits – the ones with block sizes 128 and key sizes of 128, 192 or 256 have been standardized as AES.
Rijndael uses a specified round count for the various block/key size combinations: Always $6 + \frac{\max(N_b, N_k)}{32}$ rounds (which comes to 10, 12 and 14 rounds for AES-128, AES-192 and AES-256). If you use more or less, your algorithm isn't Rijndael (and even less AES).
On the other hand, the Rijndael key schedule is flexible enough to produce an expanded key of any length, e.g. enough round keys for any number of rounds.
Have a look at my answers to How does the key schedule of Rijndael looks for key sizes other than 128 bit? and What are the practical difference between 256-bit, 192-bit, and 128-bit AES encryption? for a description of the key schedule. The schedule algorithm simply creates more subkeys from the previous ones, and thus can be simply repeated as long as needed.
Also the Rijndael encryption algorithm itself is modular enough so you can easily add more rounds – simply call the round function some more times, with additional subkeys, before the final round.
It is not clear at all whether this would improve security. It will hurt performance (though you should still be able to use the AES instructions in your processor), and it certainly will hurt interoperability. And most likely the block cipher will not be the weak point.
Don't do this for any production use, just like any homebrewn scheme.
And don't name the resulting algorithm AES or Rijndael – it isn't.