The current transaction structure is not the final variant. Later extraDataDigest field will be added, that field will be a part of the bundle essence (signed part). Setting the field value to the hash of signatureMessageFragment would allow to detect cases of changed content.
You could use obsoleteTag now (store the hash fragment into the last 27-N trytes, ...
When receiving a transaction the node checks the presence of value inconsistencies in the subtangle of the chosen tips.
Now, since a 0-value transaction has no value by definition, once it has been inserted in the Tangle I think it should be considered valid, it doesn't contain anything that can render it invalid or inconsistent with the Tangle.
With this ...
Here are some 'workshops' covering several hello world examples, including sending a simple non value transaction:
Data authenticity in general
Iota will use Qubic and Oracles.
Qubic uses a quorum to reach consensus on both the input data and the results of computations
data are only considered valid when at least 2/3 of all participants agree. Hence the term: Quorum-Based Computations The quorum makes it difficult for malicious actors to falsify data, and ...
Trying to recall something mentioned by CfB a while back, I believe IOTA will eventually use collective memory usage: In a sense that hash-based signatures will be reduced from 8192 to 64 bytes - which is over 99% compression therefore size will not be an issue. Also don't forget about snapshots