If you are asking "how can the server verify that the password (or passwords in your case) that the user enters are valid", the standard answer to that is not to have the server encrypt the passwords at all. Instead, what we have the server do is store one hash of the two passwords. That way, if someone manages to break into the server and get the hashes, that doesn't tell him anything about what the passwords are.
One simple implementation would to be to take a standard hash function (SHA256, for example), and when registering the user, compute the hash of the user-selected password concatenated with the one generated from the real password; the server would store this hash in the database (or forget the actual passwords). Then, when authenticating a user, the user would supply the passwords, the server would concatinate them, hash them, and compare that hash to what's in the database (and, of course, allow the user only if the hashes are exactly the same).
One advantage of this over encrypting the passwords is that hashing is a one-way operation; no one can reverse the hash (this is actually one of the security properties of a cryptographical hash, that give a hash, no one can find that hashes to that value). In addition, if the user enters the wrong data, it well detect that as well (as that's another of the security properties, that no one can find two values that hash to the same).
Now, if your second password is as good as you expect, that it is "almost impossible to guess", well, that's actually good enough. Even if someone broke into the server and recovered the hash, well, all they could do is make guesses for both passwords, hash them, and seeing if both guesses were correct; if one of the passwords is unguessable, well, they can't do that.
However, I rather suspect that the password might be a bit more guessable than that (after all, if it were truly unguessable, why bother with the user-chosen password at all?). If that is likely to be the case, it might be wiser to do the same approach, but with a password derivation function (such as PBKDF2); it's pretty much like a hash, but it does these nice things:
It makes provision for a "salt" (which is an additional value that is hashed in); it won't make a brute force attack on a single hashed password any harder, but it does mean that the attacker cannot attack several hashed passwords at once (because each of them will have a different salt). The server would choose a random salt when registering the user, and include it along side the hash.
It's slower to evaluate than SHA256 (and in this context, that's not a bad thing; it means that an attacker will take longer to go through his dictionary).
It also provides a "key" that's needed to do the hash evaluation; if the server stores the key separately, well, the hash doesn't do the attacker any good unless he gets the key as well.
Oh, and one thing; about your specific question about how to combine the two passwords; well, hash functions and password derivation functions don't really care; they'll work with just about anything. The only thing you need to be careful is to make sure that you combine them in a way that doesn't lose information. For example, you wouldn't want to exclusive-or them together, otherwise (as a trivial example, the two passwords "A" and "1" would hash the same as the two passwords "B" and "2"). One easy and safe way to combine them is simply concatenate the two (of if the two passwords are "Alpha" and "Omega", you'd actually hash "AlphaOmega". (Note: if both passwords are variable length, you make also want to concatinate the length of one of them if you want to be pedantic; otherwise the two passwords "AB" and "C" would hash the same as the two passwords "A" and "BC").
