Unfortunately there aren't really good solutions for either of your requests. Here is some explanation though.
For the first item - the output XML generated by a form should mimic your main datasource. The fields are named identically and the indentions (nesting) should match the folders. Infopath does put a tag or two at the top but those are necessary, and can usually be ignored when reading the XML without confusing anyone.
If you need something more readable you will have to write code to output a file that is formatted how you want. This will introduce a whole other set of problems because the form will have to have a higher trust level in order to write to a local file. You should avoid that route if at all possible.
Also consider why you need XML to be more readable - XML is supposed to be a format for uniform data storage/transfer, not a replacement for a Word document. Can't the users just open up the saved XML in Infopath and see the data in the nice format that you already setup (or do some of the users not have rights to the form template).
For the second item - Infopath stores every data item that shows on the screen as a field. This is particularly annoying in situations such as the one you describe or calculated fields (why store the calculation - just store the base fields and recalculate the display).
The best solution for this is to put all your "fake" fields into a different folder in the datasource (call it "TrivialFields" or something like that). Any code that parses the XML can just ignore it and any users that have to read the XML can easily ignore that section.
An alternative that is a significant amount of work compared to the results you get is to write code to do the work you are trying to do with the field currently. You can also write code to clear the field every time the form is saved - so the field will exist but will always be blank in the saved form.
It seems like both your questions concern an end user reading the XML source of a saved form. Instead of going down that path you should let the XML be what it is and let the user view/print from within InfoPath. You can then control the formatting and view explicitly. Any backend code you write to process the XML doesn't care if there are extra fields or confusing formatting - it is code after all.