Your idea sounds reasonable, at least in theory (and that's what we do here, right? :)
A standard way to justify and analyze a design decisions like this is via the random oracle model (ROM) methodology. Bellare and Rogaway (CCS'93) gave a nice description of ROM analysis, and are generally credited with suggesting that it be applied in practical cryptography. In the ROM, one pretends that the function SHA1(.) is
a truly random function that is available to everyone through an oracle. Of course, this is never true in reality because SHA1(.) is defined by a publicly-known algorithm. Nevertheless, ROM analysis seems to be an excellent tool for verifying that protocols and algorithms do not have certain structural weaknesses of the sort you should be worried about.
Usage of the ROM is sometimes regarded as a heuristic that theoretically results in a security weakness. In your situation, you could alternatively justify your design by assuming that the keyed function $F$, defined by
$F_K(x) = SHA1(x||K)$,
is a secure pseudorandom function. Now, this is an assumption that has a reasonable shot at being true, unlike the situation with pretending that SHA1 is a ROM.
Either way, we are searching for some way to justify that each of the HMAC keys you generate will look uniformly random and independent to an adversary. After that step, we could give a standard reductionist/"provable security" analysis of HMAC composed with your key derivation step.
(I'm ignoring issues with input/output lengths not fitting together, and so on. To do this right in a product you'd have to be much more careful about all of this than I have been. Lower-level errors can mess everything up.)