Techniques for encouraging pair programming
Having them do it for homework, and pair program is a big ask. However here is some of my experience with pair programming.

While working as part of a software team, we tried to introduce pair programming, but got lots of resistance, even from the evangelists (no one had done it before, but it seemed like a good idea).

What worked


Pairing with someone that had done it before: At one point we had a contractor that had done pair programming before, when I worked with him, I did pair programming. This experience showed me that it could work. The only people, that are available and have done it before are the year above. A good way to lean is to teach. Therefore pair students with someone from the year above. This way the student in the lower year learns to pair program, and the one in the upper year learns by helping. [You need some intensive to stop the upper year student doing too much work. There is also a bootstrap problem.]
We had read that it takes sometime before pair programming pays off (2 weeks of full time programming, if I remember correctly). We kept giving up on pair programming during this investment phase. However we did discover that if the task is sufficiently hard, then the pay off was immediate. These were problems where we both had enough language experience, the problem was well defined, but nether of us knew how to solve the problem. e.g. setting up the MMU on an ARM processor. One of us knew what they wanted it to do. The other knew what an MMU does, but nether had ever set one up before. Therefore once they have learnt to program, give them a task that would be very difficult to do on there own, and get them to pair it.
Non programming activities: for various design tasks (algorithms and higher level than code), we worked in pairs or small teams (2,3 sometimes as many as 5). This worked well for tasks that are hard. Therefore start pairing with non-programming tasks.