If you're familiar with a wide variety of programming languages/environments, C# and vb.net look like pretty much the same language.  C# looks a little lower level, a little grittier, because it uses brackets instead of begin/end (or whatever vb.net uses).  It does tend to get new language features first, while the vb.net team seems to focus on extra, friendlier libraries (which you can then turn around and use in C#, AFAICT).  Big whoopty deal.

For that matter, Java is pretty much the same language, too. (I know, saying that's just begging for flames).

Far more important than minor syntactical differences is the .net runtime which they share.  You used to be able to get a job as a programmer by learning some given language (or even just parts, if the language is as big and scary as, say, C++).  Now, in an asp.net shop, you really need to understand things like HTTP, SQL, COM, asp.net's page life cycle, SEO, HTML, javascript, Active Directory, TCP/IP, MSMQ, SOAP web services, XSLT, some complicated CMS...the list just goes on and on.  Plus you need a solid grasp on the .net framework library, and I don't think I know anyone who can claim to be an expert on that monster.

Most programmers will learn the pieces of that they need to use every day, and look up the rest as needed.  (OK, tony can probably tell you off the top of his head that there's an abstract LicenseProvider class in the System.ComponentModel namespace, and here's how you use it, but most mere mortals have probably never even heard of it...I hadn't, until I googled for something obscure just now to use as an example).

This is why projects like Iron Ruby, Iron Python, and F# are so exciting.  They're bringing higher level languages to the table, *with* that massive class framework.  But that's a different post, that I've probably already written.

The real distinction between vb.net and c# is the programmers who choose one over the other, the teams they build, and the architectural mind-set they tend to have.

C# programmers are mostly coming from the C/C++/Java world.  They tend to architect heavily up front, be really anal about the way their code looks, and think about things like design patterns, loose coupling, code optimization, and maintainability.  They also have tendencies toward elitism and snobbery (though nowhere near as bad as the common lisp fanatics).

VB.NET programmers tend to come from (surprise!) the VB world.  Or they're newcomers who get intimidated by the way C# looks.  They tend to be more of the "get 'er dun" school of thought. They're usually too busy actually writing/testing/debugging code to, say, make sure that all the equal signs in a block of assignments line up nicely.

There's nothing wrong with either approach/mindset.  It just depends on your customer's needs at the time.  Someone who can switch gears from one approach to the other, as needed, can be an invaluable asset to your team.

Like all generalizations, there are always exceptions.  I've known C# guys who came from a C background who believe copy/paste is the best kind of code re-use, because they thing inheritance is confusing. I've known programmers who prefer VB.NET because they just think brackets are ugly, but they're still doing solid enterprise-level software, dealing with COBOL back-ends and programming in assembly language for some of the embedded front-end stuff.

A programming language is a tool.  Microsoft has really upped the ante with .net, creating an entire platform.  If you're willing to tie yourself to them (and it's a safe bet that windows will be around for a long time), you have an amazing amount of power at your fingertips.  If you choose VB.NET, you might be missing out on some of C#'s whiz-bang syntactic sugar (it's been a while since I actually looked.  I'm pretty sure VB.NET supports generics now.  Does anyone know how its LINQ support stacks up?), but that isn't going to keep anyone from doing amazing things with it.
 
All programming languages/platforms have their warts.  Except maybe scheme (unless you're Larry Wall <G>), and its standard library is so tiny that I just can't find a practical use for it.  But every time I check out the different implementations, it gets more attractive.

Who's the real winner?  The programmers who work in shops where they actually let you pick and choose the right programming language/platform for a given job.

Who's the loser?  The guys who have to keep up and deal with all these different platforms.