Yes, there is nothing stopping a node from holding data after it expires. It just isn't a feature exposed in the interface, or at least, for this you need to add a toggle switch that disables the 'garbage collector' that deletes expired blocks. With bitmessage, every block is encrypted to the secret key behind the 'wallet address' style BM-*** address, so you can't use this. Also, by default the bitmessage client does archive every message your key can decrypt.

There is a system that is used in the Ethereum protocol I think, called 'Merkle trees', which allow a node to identify the depth to which one needs to store blocks to retain certainty of the chain of custody of coins. It works by turning the linear chain into a tree graph to identify the relationships between blocks and as the tree gets deeper you can identify points at which you can cut it off - more or less, making it possible to only store the data of the latest movement of any given token, and eliminating all prior data.

There is a need, of course, for the whole blockchain to be stored, but varying degrees of trimming this are necessary in order to enable features, for clients that only perform more limited functions. A small caching proxy node can capture all new transactions on the network in a size limited ring buffer that trims at the end with some margin of size to allow jitter in the overall bandwidth required to capture the new data. The caching node copies blocks into a secondary cache when it is queried, so the user's client can query it without sending out a request for blocks to other full nodes on the network, if they are new.

This is also why I have conceived the idea of adding an onion routing style protocol for full nodes. This way, transaction posts and block query requests origin can be hidden from a large, capable attacker seeking to identify IP addresses and thus physical locations of particular account operators.

If you had a caching node that pulls all new blocks off, the inbound data side of the circuit is already anonymised, same as like with Bitmessage. The routing protocol I mentioned, acts like using a Tor circuit to propagate requests and can open up a connection session between two nodes without advertising the endpoints to an external observer.

The other things that could be options a user can set for such a caching node (or indeed a full node with this routing feature added) is whether or not they want to relay some amount of those onion routed connection data, for transaction posts and/or RPC block requests, and whether they want the caching node to pass new blocks it receives on to other nodes.

Further, by using a payment system built into the blockchain, a full or caching node with a user behind it can also pay for bandwidth for relaying to a cluster of randomly selected other nodes. The purchase provides a token that proves purchase but does not give the identity of the buyer. This is added as a payment header to relay traffic, constructed from end to start each time layering over the encryption only the node can undo. The first hop unwraps it, finds a payment header/voucher, and a destination, passes the packet, and the next hop, same thing again, until it reaches the final destination. The connection remains open for a period of time, and through this back channel, the endpoint can broadcast back replies, such as the block query case. If it is just a transaction posting, the endpoint returns an acknowledgement and the circuit expires.