Not to get involved in language holy wars, but I've worked with five developers who came from VB6 to .Net, plus myself. That's not a lot, but what I saw held true for all of us.
Both languages are VERY good and I personally have no preference. I feel equally comfortable in both, and I really don't think either is superior to the other.
BUT just based on what I've seen, when moving to .Net, you're better off starting with C# for one reason only. .Net development is more about learning and using the class library, not language semantics. VB6 hides some of this by putting shortcusts into the language spec.
When you're learning a language that is not similar to what you've already done, you're more likely to look for the "right" way to do things.
Microsoft did a lot to make VB.Net easy for VB6 developers to pick up on, so you can easily code on VB.Net very similarly to what you did in VB6. This means that it's extremely easy to rely on the "shortcuts" and bring bad habits into your .Net development. So you see people who don't truly "get" things like the differences in ADO.Net and their programs have bad performance and design issues because of this.
Added several hours later based on comments
I just want to clarify that I am not stating that VB is inferior to C#. As pointed out, both compile down to the same MSIL, and both languages are good. What I meant by "VB6'ers bringing in bad habits" can be clarified with an example:
Two of the five I worked with did the same exact thing in code. They needed to get records from a database and loop through them in order to perform some maniuplation onthe data. The normal thing to do would be to either use a DataReader or DataAdatpter with a DataTable and loop through that. However, both of them instead created some array variables and looped through the DataReader results and assigned them to the arrays of arrays, and then looped through the arrays to do their calculations, meaning that they not only added unnecessary computing cycles, they also took items out of a collection that could be accesed with things like
Dim FullName AS String = CurrentRow("FirstName").ToString() + " " + CurrentRow("LastName").ToString()
to (assuming that ar is the array variable and i is the indexer)
Dim strFullName AS String = ar(i)(3).ToString() + " " + ar(i)(4).ToString()
Their method worked, but added extra cycles, and made the code harder to understand. I asked each of them why they did it this way. One of them had wanted to be able to use the data after the connection was closed so they didn't accidentally update something. This is something you would need to worry about with a RecordSet, but not with a DataReader or a DataAdapter. This was clearly someone not grasping the difference between the VB6 way of doing things and ADO.Net. The other one just felt more comfortable with arrays because she was familiar with them.
So my point had nothing to do with one language being "better" than the other. That would be arrogance and it would also be uninformed. Functionally, there is not much you can do in one that you can't do in the other. And I LIKE some of the VB.Net "shortcuts" I mentioned earlier on. (VbNewline vs System.Environment.NewLine and the whole My namespace, InputBoxes, etc).
My point was that when learning something completely unfamiliar, you're less likely to get thrown by your own preconceptions. We saw things like this go away when we switched to a C# shop from a VB.Net shop. It had NOTHING to do with the language, and EVERYTHING to do with the developers being forced to learn properly instead of taking shortcuts.
So, I still stick by my original advice for this reason, but by all means, if you like VB, go with it. And don't worry about anyone "looking down" on you for using it. All of that "my language is better than your language" stuff is nonsense. Some languages have advantages over others, but in the .Net world, in the VB vs. C# debate, both languages are actually so close that there's not much of a difference. The debate as pointless (and grown up) as the "my daddy can beat up your daddy" argument.