If I hear you correctly, you are trying to solve the problem of securely transporting $w$ and $v$ values, under the constraint of minimizing the ciphertext size.
So, what you're doing is taking the $w$ and $v$ values, selecting a random $r$ value, concatinating them into a 32 bit block, and then sending that block through Speck32 (with some key with unspecified derivation), and that's you're ciphertext.
With that procedure, I see these possible attacks:
Someone brute forces the key; Speck32 has a 64 bit key. While brute-forcing the key would be beyond the capability of a random hacker, it would be within the capabilities of a determined large organization. If your threat model requires you to be secure against such large adversaries, it's not good enough.
Someone recovers the key in another way. You don't say how you keys are exchanges, but if (for example) you have a global key that everyone uses, then if someone breaks in one device, and grabs the key, then he has everyone's keys.
Looking for repeated values. If someone sees the same ciphertext twice, then he knows the $w$ and $v$ values are repeated (and $r$, but he doesn't care about that). Assuming that $r$ is generated randomly, then you are likely to see a repeat after perhaps 16 repeats of $w, v$ values.
Modifying the ciphertext block; if the attacker is able to modify the ciphertext, he can modify it to a value to a value he hasn't seen (which would cause the decrypted $w, v$ values to be effectively random). Alternatively, he could modify it to be a ciphertext he has seen before (in which case, the decrypted $w, v$ values will be what we sent before.
So, to answer your questions:
Even with the low entropy, are the messages individually secure (i.e. the compromise of some doesn't undermine the security of the others)?
Well, assuming that the attacker can't do a key recovery attack, then the best he can do is look for repeated values. If he does see a repeat, and he knows the value in one case, he obviously knows the value in the other. This doesn't tell him anything about any other ciphertext.
Can successful guessing/statistics across a large enough set of messages compromise the key?
No, it doesn't help the attacker. If he has the resources, he can perform the brute force attack on a handful of messages (assuming he can recognize plausible $w, v$ values); more ciphertexts doesn't help him.
There's a temptation to use the last 8 bits for a MAC and/or CRC, but I fear that would make statistical attacks even better. Is that fear warranted?
Well, if you have a fixed value there (dependent on $w, v$), that increases the probability of a repeated ciphertext. Also, if you go with using $r$ as the authentication, I wouldn't bother doing a CRC or a MAC on $w, v$; those are already stirred into the ciphertext. What I would do is either use fixed bits (say, 0; those are easy to generate/verify, and is no less secure than a function of $w, v$), or if you want to add some protection against copy/paste attacks, make $r$ a function of the ciphertext context (e.g. a function of the message sequence number), and have the decryptor check it. Now, it's not great (a random change would still have a 1/256 chance of being accepted), but it's better than nothing).
Some final comments:
One thing you need to worry about is key distribution; that's quite often the Achilles heel of crypto systems. The best crypto system doesn't help if you make it easy for the attacker to learn the keys
Might I suggest you consider using Speck48? Not only does it allow larger keys (making brute force attacks considerably harder), but it allows the $r$ value to be 16 bits larger; if you select $r$ randomly, this means that practically speaking repeated ciphertexts won't happen; if you select $r$ as a function of the message context, that means that a change will have a very good probability of being detected. Of course, that means that you'll have 16 more bits to transmit; you'll need to decide whether that's a viable option.
