C# Custom getter/setter without private variable

Properties don't need backing variables (fields) at all. While they can be used for encapsulating simple fields you can also use them to access other data.

public Decimal GrandTotal { get { return FreightTotal + TaxTotal + LineTotal; } }

or

public string SomeStatus { get { return SomeMethodCall(); } }

If the goal is to simply encapsulate some field with a property you would need some sort of backing field if you are not using automatic properties.

The answer is No, you cannot do that. It is because of recursion. (See line numbers 9 and 7):

Line 1  :   public string Name
Line 2  :   {
Line 3  :     get
Line 4  :     {
Line 5  :         return FirstName + " "  + LastName;
Line 6  :     }
Line 7  :     set
Line 8  :     {
Line 9  :         Name = value; // <-- Goes back to Line 7
Line 10 :     }
Line 11 :   }

No, I'm afraid not. The compiler is smart enough to make this happen for you on auto-generated properties, but with standard properties I imagine the logic behind something like that would end up getting in the way and doing more harm than good.

For example, what if I create a property like this...

public int SomeValue
{
  get
  {
    return 0;
  }
}

Would the compiler (with the feature you're looking for) create a backing private variable? Why? It doesn't need one.

Additionally, if the private value isn't created until compilation time, what are you going to reference in your code:

public string Name {
  get { return _Name; }
  set { _Name = value }
}

What is _Name? What if you have another value somewhere else called _Name? Then what would the compiler call the backing value for this property? What if I need two backing values? Would the compiler be smart enough for that?

public string Name
{
  get
  {
    return string.Format("{0} {1}", _FirstName, _LastName);
  }
  set
  {
    // some parsing magic
  }
}

It's been asked before, but I imagine the answer is going to continue to be "no" for the foreseeable future.

An auto-property is syntactic shorthand for simple direct member access. (And I imagine one of its driving forces was simply to try to get people to stop creating public values directly.) Properties can grow in complexity well beyond that very easily and I personally wouldn't want the compiler trying to figure out what I can easily just tell it to do.