You can't ignore the header - it tells you what the encoding is. The headers are correct - the problem is that FlashLite does not support any encoding besides UTF-8. It *is* ignoring the headers, and is therefore confused about what the data actually means.
Think of it this way - pretend that every time you speak a sentence, you must say what language it's in first, something like "English: my cat is on fire", or "French: mon chat est sur le feu" (please pardon any goofy translations).
Now consider what happens if someone simply says "mijn kat is op brand". The problem here is that we have no idea what language this is to make sense of the sentence - we require that the person say "Dutch:mijn kat is op brand". That's the way XML works, though it has a default - if you don't specify otherwise, the encoding if UTF-8, which would be like saying something without specifying the language would always be English.
The problem here is that Flash *only* speaks "English" - you can speak French or Dutch to it all day long and it simply won't understand, *even* if you explicitly say what language it's in. It will always try to interpret what you say as English, and since it's not, it garbles what you say. In the case of the Dutch, a few of the words are the same or very similar in English ("is"), and some appear in English, but have different meaning ("brand").
To solve this requires that the data be "translated" by some external service - in our analogy, the "Dutch" data feed would go through a "translation" service and converted to "English". In the case of the simple POP3 client on the chumby, that could be done locally by modifying the code. For random feeds meant to be consumed by the RSS widget, it would have to be something not on the device, and the widgets would have to be modified to use whatever translation service that might be. As I mentioned, it's quite possible that Yahoo Pipes or Google App Engine could do this, depending upon how good their XML parsers are.