Security within a deleting blockchain model Assume a blockchain model that contained no transaction data - just pure data. After a set time this data would simply be deleted, and entire blocks would be removed. How would the security model of the blockchain suffer? Would it make it easier for a "long chain" attack, and if so how can this be prevented?

The idea is to store data into the blockchain. Anyone could store data in this chain, and all nodes have a copy of this chain. There is a block race, to secure the blockchain as normal, but there would be no rewards since this is not a money based system. How the deletion is done is yet to be explored, but basically all nodes would agree all blocks older than x months be deleted from their systems.

Would an attacker be able to compute a longer chain if they know of the point at which data is deleted, then show this to the network and then make the network believe this is the correct and valid chain? If so, how can we stop this? (Assume the attacker has less than 51% computing power.) I have looked into timestamps, and time capsule based encryption, but what I want is a mechanism where an attacker cannot successfully create a block without some information that would only be revealed on a specific day.
Your system is pretty easy to implement. The major reason why Bitcoin nodes don't delete old blocks is that old transactions are needed to tell if new blocks are valid. But if the validity of new blocks doesn't depend on old blocks, than the contents of those blocks can be deleted without consequences.
You mention the problem of having a node on the network pretend that an old block is new. Bitcoin solves this problem in three ways:
Separate block header and block contents; keep block header forever
Bitcoin block headers are 80 bytes. They look like this:
&lt;4 byte version&gt; &lt;32 byte hash of previous block header&gt;
&lt;32 byte hash of the block contents&gt;  &lt;4 byte timestamp&gt;
&lt;4 byte difficulty&gt; &lt;4 byte nonce&gt;

That's small enough to avoid having to delete the block headers, ever, but enough to include a merkle root of what's in the block. You can delete the block, but keep the block header around. The difficulty field is necessary because Bitcoin difficulty can vary. The 4 byte nonce is added to make mining easier.
Record timestamp in block header
The timestamp is recorded in the block header, and the Bitcoin client rejects any block headers that are too far into the future or the past.
Record previous block in block header
Bitcoin includes the hash of the previous block header in the block header, which means that you can't take a previous set of block headers and pretend that they're new.
For example, if you've got these block headers:
A&gt;B&gt;C&gt;D&gt;E

You can't take C and append it to E, because other nodes will notice the mismatch between E and C's parent, B.