Can the External ID have multiple values
The External ID field isn't just a regular field--it allows matching by ID alone.  It would be a waste to have External ID be concatenated fields, for a couple of reasons:


You can't search easily.  If you have a contact with an ID from System 1 of "123" and an ID from System 2 of "789", and you concatenate with a "|", you'd have a value of "123|789".  If you search for an External ID of "%123%", you'd catch "123|789" as well as "222|123" (i.e. the record with ID 123 in System 2) and "1123|789" (i.e. any ID with those digits in order, regardless of position).
You lose auto-matching on import.  If you're doing a later import from the external system, you won't be able to identify the External ID and have it match.  You'll need to use a matching rule or the CiviCRM ID.  This makes it no better than a regular custom field.
You may have trouble importing in the first place.  If you're importing from System 1, you'll know that system's external ID, but you might not know the corresponding contact's ID in System 2.  You'd need to do some spreadsheet tricks like Joe suggests, and you'd have to match up the two systems' records in the spreadsheet before you even start.
You'll never be able to merge records reliably.  If Sammy is ID 123 in System 1 and Samuel is ID 789 in System 2, you might not catch that they're the same guy.  They might end up as separate contacts in CiviCRM, but when you merge them, you'll only be able to concatenate the IDs by remembering the one that gets lost and going back to edit the External ID manually.


All in all, there's no advantage to cramming multiple values into the External ID field, and it has distinct disadvantages (merging and searching, in particular) as compared to regular custom fields.  You should simply decide that one system's ID is the External ID and the others are custom fields.  If it would be ambiguous, make them all custom fields; that's still better than mixing up the External ID field.