Can I use HMAC-SHA1 in counter mode to make a stream cipher? Say I have an embedded device which is only capable of doing HMAC-SHA1 transformations (that device is, in fact, a YubiKey).

Would it be secure to feed it like a block cipher in counter mode to get a random pad suitable as an stream cipher?

Of course, I'm talking about not repeating the counter value ever to encrypt data (so this construction would also need some random IV or treating the counter value as a nonce forever).
Yes, this would be secure. CTR (Counter) mode based on keyed function $F_K$ is secure as long as its output
$$
W_i = F_K(i)
$$
is unpredictable given previous outputs
$$
F_K(1),F_K(2),\ldots,F_K(i-1).
$$
This requirement is essentially the definition of a pseudo-random function (PRF). Most HMAC instantiations with widely used hash functions are believed to be secure PRFs (rigorous proofs are impossible for several reasons). 

You may have heard of CTR mode as a blockcipher mode. This is also correct, as a secure block cipher must be a secure pseudo-random permutation (PRP), which can not be distinguished from PRF if it is queried/used fewer than $2^{n/2}$ times, where $n$ is the block size. 

Block ciphers are used in CTR mode primarily due to their speed (HMAC is slower, in particular on short messages), but keyed hash functions are equally strong.

Certainly, you must ensure that your counter never repeats. You may want to follow the NIST strategy (page 18) of constructing the counter from nonce.