The main idea behind the agile methods is to help you be productive - in a positive sense. No one cares if you spend an hour surfing every day if you meet the deadline. Everyone gets mad if you surf half an hour every day but miss your deadline. The solution: Make it easier for you to meet the deadline.
As you noticed, pair programming makes sure you stay focused (among all the other advantages like improving skill/knowledge spreading, better code, less bugs, uniform design, etc.).
I found that discipline is always a struggle for me. If I pair with someone, chances are that one of us wants some work done today and pulls the other along. So the "work for a month" often becomes turns into "work together for one week", being surprised how that huge amount of work resolved in the end, spend a day or so recovering (refactoring, fixing TODOs in the code, adding a couple of tests, surfing with a clear conscience) and then grabbing the next month of work.
Net result: I'm much more relaxed (more because than despite the constant supervision), team cohesion is much better, work gets done more quickly, people don't hang around some minor issue for hours or even days (because someone else can spot the problem much faster).
When you say "you may actually feel ashamed", isn't that a good thing? It means you feel that you did wrong and you should. You're not getting paid to get nothing done. Not getting anything done makes you feel helpless, unhappy, unworthy, miserable. Instead of feeling ashamed, stand back and think "Why didn't I accomplish anything today?" Do you need help? Is there something you don't understand? Is the current task too hard? You don't like it? Maybe you can switch the task with someone else. Maybe someone else can help you get through. Agile means: Assume responsibility instead of being micro-managed like a puppet on strings. You need a tool? Go to your boss and ask for it. Learn to argue. Learn to stand up and shout when you have to.
As for tests, there is a sweet spot when your code suddenly collapses from "nice" to "perfect". That's the moment when you notice that you need to implement feature X and you thought that will be a nightmare and suddenly realize that the code is almost there. Just a small refactoring here and there. A new class and done. Four weeks of work suddenly became a day. Victory! Triumph!
Short Answer: Absolutely positively.
Long Answer: Unit tests are one of the most important practices I try and influence at my place of work (large bank, fx trading). Yes they are extra work, but it's work that pays back again and again. Automated unit tests not only help you actually execute code you're writing and of course verify your expectations but they also act as a kind of watch dog for future changes that you or someone else might make. Test breakage will result when someone changes the code in undesirable ways. I think the relative value of unit tests declines in correlation with the level of expected change and growth in a code base, but initial verification of what the code does make it worthwhile even where the expected change is low. Unit test value also depends on the cost of defects. If the cost (where cost is loss of time/money/reputation/future effort) of a defect is zero, then the relative value of a test is also zero; however this is almost never the case in a commercial environment.
We generally don't hire people anymore who don't routinely create unit tests as part of their work - it's just something we expect, like turning up every day. I've not seen a pure cost benefit analysis of having unit tests (someone feel free to point me to one), however I can say from experience that in a commercial environment, being able to prove code works in a large important system is worthwhile. It also lets me sleep better at night knowing that the code I've written provably works (to a certain level), and if it changes someone will be alerted to any unexpected side effects by a broken build.
Test driven development, in my mind is not a testing approach. It's actually a design approach/practice with the output being the working system and a set of unit tests. I'm less religious about this practice as it's a skill that is quite difficult to develop and perfect. Personally if I'm building a system and I don't have a clear idea of how it will work I will employ TDD to help me find my way in the dark. However if I'm applying an existing pattern/solution, I typically won't.
In the absence of mathematical proof to you that it makes sense to write unit tests, I encourage you to try it over an extended period and experience the benefits yourself.
Best Answer
Your question is orthogonal to your problem. Sticking two programmers that don't want to or can't write good unit tests together isn't going to get you more/better unit tests.
Sticking a programmer who is poor at writing unit tests with one that is good might propogate good habits, but might not be a good pair for other reasons (unit testing is only a part of the entire development process after all). There are other questions/posts that deal with pair programming's benefits and problems.
Your goal should be to change the culture that caused the problem in the first place. Well done pair programming can help that, but it will usually require a combination of things all pushing towards that end goal. There is no silver bullet (pun intended) for making people write good unit tests.