I'd say the second design is better. Less items and easier inheritance path.
The first design has unnecessary interfaces, which you don't really need unless you're implementing something else which implements the interface, but doesn't inherit from the base class.
What's the difference betweeen a Table and a Table<string>? In other words, can you not just use Table<string> as your nongeneric form?
If you do go for the second option, I'd suggest renaming one of your Rows properties - you may be able to get away with having two properties of different types through hiding etc, but it's not going to be pleasant.
How much behaviour will your Table type actually have? If it's really just a container, you may not need an interface - but if it's got significant logic behind it, you may want to have an interface so that you can mock out the table when testing a class which uses it.
I would use generics in the rows, without involving string in the base class, and have the non generic inherit the Table class. Consider not using the abstract class.
Table<T> -> Table:Table<string>