I think others already provided good answers but I'll add mine only because I think your team just transitioned to Scrum and now you guys are in a very similar position we were when we started.
First off, our intoduction to Agile and more specifically Scrum wasn't very smooth. Basically management came down and said, from this day forth you shall do Scrum and this is a process you will all follow. So much for People over Process.
The process we originally followed (blindly, I might add) ended up very similar to how you described. People get assigned tasks, everyone gets booked and we all go back to our desks and plug away. Then we have a boring stand-up meeting everyday.
The key to realize is that Agile, and Scrum included, is actually about people. When the team goes into iteration planning, don't let your Scrum master (who is probably your manager) to assign you hours, stories and tasks. It is completely UP TO THE TEAM. I think for a lot of people this is a very hard concept to get through because for years before that they'd come to work and they would have a boss (manager, technical lead...) who would simply assign work. They dive into Scrum but everyone (including scrum master himself) continues to operation in the same mode.
One day, you'll get sick of this, so you'll start reading books, blogs and keep asking questions like this on stack exchange. The realization that you will get is that you as the developer and your teammates should be the driving force behind committing to stories and assigning tasks. If you guys feel you will benefit from pair programming, by all means create a 2 tasks for each of the engineers and assign both of them hours. The only thing scrum master should be doing is measuring velocity against completed stories that you delivered AS A TEAM in the previous iteration.
Also another thing that bugs the crap out of me is how people are told that their capacity IS ALWAYS 75% of total hours, so that's what they commit to and then for the entire duration of the iteration they complain that a) they can't help you or b) they can't do the right thing because they've been assigned too many hours. People should not be told how many hours to commit and they certainly should push back if scrum master is attempting to pull something like this! Everyone should commit to exactly what they are comfortable with. For example, I'm a team lead and frequently I'd end up in a random unplanned design discussion, or helping someone with code, or with troubleshooting weird stuff, so my capacity is never above 50%.
It took our team 4 release cycles to learn not to do the things I just mentioned and even though we've definitely improved, if you ask the experts we are not even half agile. So still a lot of learning to do.
Update 1: Response to Cliff's comment
Well you offered your ears so here it is...
You are right, cultural shift is key, but this shift doesn't need to happen at the executive level. Your own group manager can change the culture within your team and isolate you guys from corporate BS that he has to deal with. What you are describing was EXACTLY us about from 2007 to 2010. Our team (and other teams as well) flopped release after release. In one of the releases using management's "process for being agile" we manage to have 9 people produce the work that would usually be done by a single person and it took us double the time. I had so much free time, that I even updated my resume.
Then, I had a conversation with my boss and explained all these things to him how agile is about people and that if you want us to care about the product, let us make decisions that affect how we work on and deliver the product. I think he decided to make it an experiment out of it, he made every single change we... well, mostly myself, but I talk with the rest of the team a lot, hence 50% capacity :) ... proposed. It's possible that he figured that if he makes all the changes we are asking for and we still fail, he'll come back with a victorious "I told you so".
So in the last 12 months, we've eliminated so much "stupid" it's not even funny. Our stand-up meetings actually make sense now because we work together, not in isolation. We still have ownership (at least for now) of specific parts of the product, but we also cross very frequently into each others code. We constantly do code reviews so that not only team members learn other code, but they also learn better coding and design techniques. We've broken monolithic, giant "agile" team into 3 different teams so planning and other meetings are much shorter and people actually care about them because they don't sit around and listen about things they don't care about. I've seen nights when 4 out of 5 of our guys (one of the teams) would be online at 11pm at night and nobody actually told us we have to work hard or ever pressured us to work over 40 hours. People who couldn't care less half a year ago, all of a sudden are engaged and excited about the work they are doing. And all it took was for our manager to do was say, "you guys decide what is right and do what you need to do and I'll keep corporate BS out of the team as much as I can."
It started as experiment (my suspicion, he never told me that), but now our group is kicking butt compared to other development groups in the department and we even have other developers who are now trying to come over and join us.
The biggest hurdle for us ever since this change happened (and still a problem today) was the fact that engineers in normal corporate environment are like experimental mice in a cage. Even when your manager decides to go truly "agile" and removes the cage, everyone has been in that cage for so long, they don't even realize they are free. So even with all the freedom, they continue acting as if they are still constrained. I think what would help is to have at least few people on the team (such as yourself), who go outside the boundaries of the group and seek out better ways of doing things. Then come back into that group and stir it up a little.
In your case maybe paired programming isn't a solution if you are looking for another external force to come down onto the team and tell them how to work. Instead, throw the rules out, sit down with them, without management, and ask them what they want to do? what will make them happy? productive? Identify biggest problems and then ask THE TEAM what they think solution should be.