The answer to your question depends on whether or not you empasize security over performance and potentially how many records we are talking about. You can create a secure solution that won't scale very well by creating the same symmetric key on both servers by using identical values for key_souce and identity_value for the CREATE SYMMETRIC KEY command. All server side encryption in SQL Server is non-deterministic, meaning that the same value encrypted twice with the same key will result in different encrypted values. Therefore, you won't be able to join the data without decrypting it. If the data is decrpted on each server before it's combined, then you will want to add an SSL Certificate directly to the SQL Server to encrypt at the transport level.
Alternatively, you could put the key on only one server and always perform a remote join on the server with the key after encrypting both tables with it. You would still want an SSL certificate on the instance if you require that the result is returned unencrypted.
Another idea would be to use an Extensible Key Management system, which is a hardware security module that offloads encryption processing and would allow the same key to be used by both systems.
Since server side encryption is non-deterministic, you won't be able to index it. There are two potential solutions to that issue. One is to create a hash on part of the original data and index that to help improve performance and the other would be to use an deterministic method for encryption that is either external or encapsulated in a CLR that is installed on both systems. Be careful with hashes because they are deterministic and can be reproduced easily, so avoid hashing the entire value. If anyone can use the CLR or external encryption who is not authorized, then it's possible that a hash table can be created by running all possible values through the system and then it can be joined back to the original data.
To encrypt in SQL Server, you will also need to use varbinary columns instead of numerics.