Q:

Are there any reasons to use private properties in C#?

I just realized that the C# property construct can also be used with a private access modifier:
private string Password { get; set; }

Although this is technically interesting, I can't imagine when I would use it since a private field involves even less ceremony:
private string _password;

and I can't imagine when I would ever need to be able to internally get but not set or set but not get a private field:
private string Password { get; }

or
private string Password { set; }

but perhaps there is a use case with nested / inherited classes or perhaps where a get/set might contain logic instead of just giving back the value of the property, although I would tend to keep properties strictly simple and let explicit methods do any logic, e.g. GetEncodedPassword().
Does anyone use private properties in C# for any reason or is it just one of those technically-possible-yet-rarely-used-in-actual-code constructs?
Addendum
Nice answers, reading through them I culled these uses for private properties:

when private fields need to be lazily loaded
when private fields need extra logic or are calculated values
since private fields can be difficult to debug
in order to "present a contract to yourself"
to internally convert/simplify an exposed property as part of serialization
wrapping global variables to be used inside your class

A:

I use them if I need to cache a value and want to lazy load it.
private string _password;
private string Password
{
    get
    {
        if (_password == null)
        {
            _password = CallExpensiveOperation();
        }

        return _password;
    }
}

A:

The primary usage of this in my code is lazy initialization, as others have mentioned.
Another reason for private properties over fields is that private properties are much, much easier to debug than private fields. I frequently want to know things like "this field is getting set unexpectedly; who is the first caller that sets this field?" and it is way easier if you can just put a breakpoint on the setter and hit go. You can put logging in there. You can put performance metrics in there. You can put in consistency checks that run in the debug build. 
Basically, it comes down to : code is far more powerful than data. Any technique that lets me write the code I need is a good one. Fields don't let you write code in them, properties do. 

A:

perhaps there is a use case with nested / inherited classes or perhaps where a get/set might contain logic instead of just giving back the value of the property

I personally use this even when I don't need logic on the getter or setter of a property.  Using a property, even a private one, does help future-proof your code so that you can add the logic to a getter later, if required.
If I feel that a property may eventually require extra logic, I will sometimes wrap it into a private property instead of using a field, just so I don't have to change my code later.

In a semi-related case (though different than your question), I very frequently use the private setters on public properties:
public string Password 
{
    get; 
    private set;
}

This gives you a public getter, but keeps the setter private.

