The client can temper with any data they send you, so you have no guarantee that your own client-side code has generated the non-input data. However, you should not be obligated to stop a client from burning themselves when they try to hack your system.
Ask yourself this - is invalid data in those non-input fields a problem only for the client, or is it a problem for your system and/or other clients?
If it's a problem for the system and/or other clients, then by all means validate it. You don't want other clients to suffer from hacking mistakes, and you don't want your server to get hacked.
However, if it's a problem only for your client, you don't have to go out of your way to solve it. After all - they are hacking your system. You want to protect your clients from mistakes when they use the UI or web service you provide them, but if they try to find backdoors and make mistakes it should be their own problem.
For example, if you client-side code collects locale data from the clients machine so your server can correctly generate time&number formats and convert to the proper units when rendering the pages. The client hacks your registration form and send the registration data directly via HTTP request, but they got the locale format wrong and now they get dates in the Gibberishian calendar and lengths are displayed in Pounds.
I say - it's their own freaking problem for hacking your system!
You can be extra nice and validate that data for them, but nobody should blame you for poor hacking-support...
That being said - you should really make sure that this is the case before deciding not to validate that data. For example, if the client posts data that is being parsed based on his locale and displayed to other clients, you'll want to validate that locale so you won't ruin that data for the other users.