It could be a bad practice, were it not for the fact that it's already pretty obvious what you're talking about in your code, based on context.
Dog = new Dog();
Which is the type constructor? Which is the object? Not confused? OK, how about
Dog = Dog.Create();
Which is the object? Which is the static factory method on the type? Still not confused? I didn't think so.
The only time I've seen this be a potential problem is when the namespace tree gets fairly elaborate, and the compiler can't figure out the ambiguity, in which case you wind up with something like
Dog = new Some.Namespace.Dog();
In any case, this should only happen with Automatic Properties (and perhaps enums), since local variable names are always camelCased, avoiding the ambiguity entirely.
dog = new Dog();
Person
class containing aDog
property calledDog