Will deadlocks occur when deleting rows from a table that is being added to by another process?
The rows to be archived are selected by a column that has the Identity property


In this scenario, you're inserting rows at the end of the index, and deleting rows from the beginning.  So there shouldn't be overlapping locks that would lead to deadlocks.

This assumes that your archive process won't ever run concurrently.  Multiple concurrent archive operations could conceivably deadlock with each other, since they'll be operating on the same range of rows.  You should make sure that doesn't happen by, for instance, scheduling this as a SQL Server Agent job.

Just make sure not to delete too many rows at once from the "live" table after archiving them, as this could lead to lock escalation (which sounds like it would be undesirable in your situation).  Check out Michael Swart's excellent article about that topic of doing batch processing in a way that promotes performance and concurrency: Take Care When Scripting Batches

Even though your main table is a heap, you should still be okay with regards to deadlocks, as all your queries will tend to seek on the nonclustered PK and delete using the RID from there.  It seems possible that you could experience page level blocking (or deadlocks) within the heap itself, depending on a lot of factors, but it would be hard to know for sure without seeing the workload in action.


  Should I set the DEADLOCK_PRIORITY to LOW to ensure that if a deadlock does occur that the archival process will be killed and not the running application?


Yes, that's a reasonable step to take.  And as you mentioned is a good way to make sure the archive workload is re-prioritized with regards to concurrency.


  Should I also set TRANSACTION ISOLATION LEVEL?


The default isolation level (READ COMMITTED) should be okay in this situation.