At my work we have the following procedure for code reviews. It has worked well for us so far, and we found it to be very time-efficient, especially in terms of man-hours. We do not really have any specific time allocated to the reviews. Every commit or merge to the trunk must be reviewed, and it takes as long as it takes for the reviewer to ok it.
Edit:
The time it takes, of course, depends on the magnitude of the change. Small features and bug fixes take minutes. Large new features, refactorings, or changes that affect many parts of the system can take half a day to review and another day to address all the issues that come up as a result.
To make this system work it is crucial to commit to the trunk often, so that the changes are of manageable size. You do not want to have the situation when you have to review a year's worth of somebody's code.
Look at how facebook does it with their own app, called phabricator: http://phabricator.org/
They basically commit on a per issue basis, and for each issue, the code is shown, which is to be reviewed by someone. The code doesn't go into their main repository until the reviewer said it's ok to do so.
I guess it makes it more fun.
Also, perhaps a code should be assigned to two people: one who does it and one who reviews it.
Albeit perhaps your teammates don't believe in this review thingy.
Personally, in lack of reviewers, I used unit tests for lower-level functions and "the janitor test" for all the rest: the janitor test is called that way, because even the janitor should be able to understand your code.
I usually removed some minor parts, like block / function scope brackets, visibility notations, sometimes even types, and showed it to managers, domain experts, mates, whoever requested the code: "is this what you want?"
Also, going there personally and not leaving until reviewing is done helps.
Or, in case you're not fine with the team, or they're not fine with you, you know, "if you can' change the company, change company"...
Best Answer
We don't choose reviewers.
In our team:
Code Reviews aren't assigned, people pick them up when it works for them. The understanding is that we can't push stories through the pipeline. On occasion someone will mention that they're awaiting a CR in the standup but that's about it.
I like this model, it gives people to pick up what they can and avoids "giving people jobs".