Splitting a large table
We now have a table with over two billion rows and 700GB of data. It's
  a small number of columns, one being a 256 char varchar used to store
  serialised blob data. This is now of a size that when people try to
  insert, delete and update to it (via the app) users occasionally lock
  each other out. This can only get worse as time goes on.


Why do users lock each other out?  Is it that they are all accessing the same rows?  Perhaps the real solution to improve performance is query and index tuning so that only the needed data are touched regardless of table size.  

Archiving read-only historical data will improve performance of full scans, improve manageability of current data, and perhaps reduce I/O due to a the smaller working set of active data.  You could simply move old data to an archive table in the same database during a scheduled daily process.  Rather than have users invoke a separate process to copy the data back, consider using a UNION ALL view of current and archived data when users need to report on both current and read-only historical data.