Is there a good way to introduce reviews?
There are probably several good ways, depending on your team and the benefits you hope to get from reviews, but any approach will have some common features:
explain what you expect: This is a new process for your team, or at least a change to the existing process, so it's only fair to let the team know why you're instituting the change, how you expect the team to benefit, and how you'll know whether it's working.
define the process: Walk people through the process you want them to follow for reviewing code, discussing changes, etc., so that everyone on the team knows how to proceed.
define the criteria: Lay out the kinds of changes that people should and shouldn't call out as needing improvement. For example, bugs and significant performance improvements are good to point out; coding standards, readability, and maintainability issues should be noted but not dwelled upon; matters of personal taste or style should be left alone.
discuss behavior: Point out that the goal is to improve code and foster a common understanding that will help the team write better code across the board, not to embarrass anybody, settle scores, etc. Critiques should be objective and constructive, never personal. Laying down some ground rules may help to ease qualms about having code reviewed.
put yourself in the hot seat first: Whether you plan to have individual reviews or group reviews, it's probably a good idea to go through the first few as a group. The first review should be of your own code so that other team members can see that the process isn't so bad and that you're willing to go through it yourself.
Start by holding a kickoff meeting to explain all of the above and address team members' concerns. Follow up with e-mail that documents the process.
I sense a large reluctance from the team, because it's just one more thing to do, and conversations can get painful.
Those are two distinct concerns. If you believe that reviews will be helpful, then you need to build time into the schedule to do them. Make sure that team members understand that reviewing is work like any other task, not something additional that they have to do while continuing to complete other tasks at the same rate.
Group review meetings should be led by a facilitator who keeps the discussion moving along, limits meeting length, and keeps things constructive. That should go a long way toward avoiding painful conversations. By the time you're ready to start individual reviews, the team will hopefully have adopted behaviors that help them keep things constructive on their own.
You should also review the review process from time to time. Get the team together every so often to discuss the process: how well it's working, how it could be improved, what practices should be abandoned, etc. Give the team ownership of the process and freedom to try new things.
