Creating custom objects with custom properties using generics

public class MyBuilding : Building
{
    public int MyId { get; set; }
}

public class HisBuilding : Building
{
    public int HisId { get; set; }
}

Why do you have the id as properties of the subclasses, it's a candidate for a base class member:

public class Building
{
  public int Id { get; set; }

If the subclasses must have specialized names for their Id property, then provide that as:

public class MyBuilding : Building
{
    public int MyId { get { return Id; } set { Id = value; } }
}

but that is a rather odd concept that you should avoid if possible.

The same holds for Cities.

public class MyCity : City
{
    public int MyId { get; set; }
    public IEnumerable<MyBuilding> Buildings { get; set; }
}

Normally you would have a materialized data set for buildings instead of an IEnumerable<T> - unless you're creating the instances lazily/dynamically. You could maybe consider using a IReadonlyList<T> as type, if you don't want it to be modifiable or else just a IList<T>

public static KeyValuePair<TCity, IEnumerable<TBuilding>> GetData<TCity, TBuilding>()
    where TCity : City, new()
    where TBuilding : Building, new()
{
    TCity city = new TCity();
    IEnumerable<TBuilding> buildings = new List<TBuilding>();
    return new KeyValuePair<TCity, IEnumerable<TBuilding>>(city, buildings);
}

If you changed the City base class to a generic like:

public class City<TBuilding> where TBuilding: Building
{
  public IList<TBuilding> Buildings { get; set; }
}

and dropped the buildings on the specialized cities, then you could return just the city from GetData, because you can initialize the Buildings property inside GetData, which I would rename to CreateCity()

public static TCity CreateCity<TCity, TBuilding>()
where TCity : City<TBuilding>, new()
where TBuilding : Building, new()
{
  TCity city = new TCity();
  city.Buildings = new List<TBuilding>();
  return city;
}

Ideally you could have a common baseclass for City and Building, because they share some significant properties like Id, Area and Name:

public abstract class AreaObject
{
  public int Id { get; set; }
  public string Name { get; set; }
  public double Area { get; set; }
}

A complete refactoring of your data model could then be:

public abstract class AreaObject
{
  public int Id { get; set; }
  public string Name { get; set; }
  public double Area { get; set; }
}

// For convenience a city base class without the generic type parameter:
public abstract class City : AreaObject
{
  public abstract IEnumerable<Building> GetBuildings();
}

public class City<TBuilding> : City where TBuilding : Building
{
  public IList<TBuilding> Buildings { get; set; }

  public override IEnumerable<Building> GetBuildings()
  {
    return Buildings;
  }
}

public class Building : AreaObject
{
  public int Stories { get; set; }
}

public class MyBuilding : Building
{
  public int MyId { get { return Id; } set { Id = value; } }
}

public class HisBuilding : Building
{
  public int HisId { get { return Id; } set { Id = value; } }
}

public class MyCity : City<MyBuilding>
{
  public int MyId { get { return Id; } set { Id = value; } }
}

public class HisCity : City<HisBuilding>
{
  public int HisId { get { return Id; } set { Id = value; } }
}

It's a little odd to have two different sub cities having specialized buildings instead of just Buildings, but you may have reasons for that? (What if MyCity buys a building from HisCity can it then change from His to My?)

Here is the code I have for building the IEnumerable inside my GetData method:

public static IEnumerable<TBuilding> GetBuildingData<TBuilding>()...

If that is going to be used inside GetData() shouldn't it then take a city id as argument in order to minimize the query? If so you can change the GetData to:

public static TCity CreateCity<TCity, TBuilding>(int id)
where TCity : City<TBuilding>, new()
where TBuilding : Building, new()
{
  TCity city = new TCity();
  city.Buildings = GetBuildingData<TBuilding>(id);
  city.Id = id;
  return city;
}

And you'll then have to modify your database query to only return the buildings for that city:

public static IList<TBuilding> GetBuildingData<TBuilding>(int cityId)
where TBuilding : Building, new() {...}

All in all this could simplify your use case to:

  int cityId = -1;
  string strInput = Console.ReadLine();
  int.TryParse(strInput, out cityId);
  if (cityId > 0)
  {
    City city = null;

    switch (cityId)
    {
      case 1:
        city = CreateCity<MyCity, MyBuilding>(cityId);
        break;
      case 2:
        city = CreateCity<HisCity, HisBuilding>(cityId);
        break;
      default:
        throw new InvalidOperationException("Invalid Id");
    }

    string json = JsonConvert.SerializeObject(city, Formatting.Indented);
    Console.WriteLine(json);
    Console.ReadLine();
  }

Update

As mentioned a couple of times in the above, the data model and class structure for especially City is rather unusual. A more conventional structure could be something like:

public abstract class AreaObject
{
  public int Id { get; set; }
  public string Name { get; set; }
  public double Area { get; set; }
}

public abstract class City : AreaObject
{
  public IList<Building> Buildings { get; set; }
}

public class MyCity : City
{
  // Uncomment if you really need this: public IList<MyBuilding> MyBuildings => Buildings.Where(b => b is MyBuilding).Cast<MyBuilding>().ToList();
}

public class HisCity : City
{
  // Uncomment if you really need this: public IList<HisBuilding> HisBuildings => Buildings.Where(b => b is HisBuilding).Cast<HisBuilding>().ToList();
}

public class Building : AreaObject
{
  public int Stories { get; set; }
}

public class MyBuilding : Building
{
}

public class HisBuilding : Building
{
}

As shown, City owns the Buildings property. The original concept of having specialized building properties per city sub class, doesn't make much sense in real life, because what defines a building: its relation to a city or its materials, functionality etc.? Can't two cities have a copy of the same building? And a MyCity should be able to Buy a building from HisCity etc. And a city should be able to own different types of building.

The factory method could then be simplified to this:

  public static TCity CreateCity<TCity>(int id)
    where TCity : City, new()
  {
    TCity city = new TCity();
    city.Buildings = GetBuildingData(id);
    city.Id = id;
    return city;
  }

  public static IList<Building> GetBuildingData(int cityId)
  {
    // The sql stuff...
  }

And the use case to:

  public static void Run()
  {
    int cityId = -1;
    string strInput = Console.ReadLine();
    int.TryParse(strInput, out cityId);
    if (cityId > 0)
    {
      City city = null;

      switch (cityId)
      {
        case 1:
          city = CreateCity<MyCity>(cityId);
          break;
        case 2:
          city = CreateCity<HisCity>(cityId);
          break;
        default:
          throw new InvalidOperationException("Invalid Id");
      }

      string json = JsonConvert.SerializeObject(city, Formatting.Indented);
      Console.WriteLine(json);
      Console.ReadLine();
    }
  }