Not really, the most bugs are found during the initial deployment of the software. After that its usually a gradual set of bugs, mostly caused by modifications to the code or addition of new features. Nothing like the initial code release. As the developers who made the original product die off, and upgrades cease, then too the bugs come to a grinding halt.
Short answer is "yes". Long answer is that the bathtub distribution isn't a very good model, because of the lack of continuity in the way failures work. Say for example that an input value of 42 causes a divide-by-zero error; then the distribution of those failures will be exactly the distribution of 42 values in the input. It's not like hardware, as you say: software doesn't fail over time, it fails when it's wrong.
Now, it may be that you're misusing the words here: you my mean a defect rather than a failure. A failure is one occurrence of incorrect behavior; a defect is a flaw in the implementation, a "bug".
The appearance of defects in software tends to have a bathtub-like distribution, but it really isn't anywhere near as clean as your picture: bugs tend to be observed early and taper off, then spike on patches and new releases, with a general upward trend starting farther into the life of the software. Even that takes careful definition, though, as you really are talking about defects observed per unit time.
Now, having said that, modern SE practices tend to change the actual rates but not the distribution of observed defects over time. "Modern" here is worth a little definition too: the Space Shuttle HAL software have very low defect rates, using SE techniques that were "modern" 20 years ago: strong specification, structured programming, rigorous review and OCD version control and testing. Extreme Programming tends to have low "defect" rates, but many of the things more traditional methods would call "defects" XP calls "user input" — since there's no finite and rigorous definition of what it should do, a "defect" is just another story.
There have been decent studies to show that XP/TDD do result in low defect rates, but I'd be very surprised if the defects/unit time distribution is a different shape.
I think there is some (small) truth in the graph. After the first release or two, you're introducing new functionality and new bugs along with the bug fixes to previous bugs, so I think you've got a constant flow of new bugs. But after a while the code base becomes fragile and hard to maintain, and so I believe the flow of new bugs goes up sharply. That's when finally (hopefully) you can convince your bosses to stop patching and start re-engineering.
The bathtub curve is really a descriptor of hardware failures (and a good one, at that) not software.
However, there is something similar going on with software. Generally speaking in most software production, our ability to create complexity has continued to slightly outpace our ability to handle it --- i.o.w. there is some sort of Peter principal at work where software systems (collectively) grow in complexity until they become unmanageable, and then stay there. So while today we're much better at handling some of the systemic problems of the 1990's, than we were back then, we're not much better at handling the systemic problems of the 00's. Such is life.
I don't think this looks quite like a bathtub, though.
I think a lot of it depends on how well it is maintained. I've got one large GUI application where I'm practically the only programmer that's maintained it, and its defect frequency has steadily decreased over the years, and I don't anticipate it going up at any point in the future.
However, had I let a junior programmer maintain it, I wouldn't feel the same way, as there is a great temptation for a maintainence programmer to code a 'good enough' fix and not 'the correct' fix. I can't blame him entirely, he probably doesn't have the knowledge of the code that the original programmer did.
Regarding the right side of the bathtub, if you consider external factors, such as Operating Systems, then there can be some correlation, as I've had some apps that newer versions of Windows broke, usually through no fault of the app. But this is a relatively small number.