Well you could simply use a coded IDENTITY or similar.  By coded, I mean
generating the new ID in a central table, and on each server the identity
seed is different, e.g. on central it starts at 1, on remote it starts at
something like 2000000 or some reasonably large number that you won't get to
in central.  INTs are big and BIGINTs are bigger; for the latter you could
spread the numbers out over a million servers and still have plenty of room
to grow for just about any business model.  In addition to ensuring
uniqueness, this way when you replicate data back to central, you know which
rows were created on the remote system (which a GUID wouldn't tell you).

However, now that I mention GUID, I am thinking about one of your final
comments.  If the systems cannot talk to each other, and regardless of what
methodology you use for your surrogate key, what are you going to do to
consolidate when the remote server creates a new row where the six columns
are the same as a row that already exists in the central database?  (Even if
you are using replication, let's say that row was created just before the
server went down, and the row was never copied to remote.)  You can't
prevent the new row from being inserted, because you don't know such a row
already exists!