The accessor for your properties in your ObservableIdPair should not have get in front of it, otherwise PropertyValueFactory won't pick it up.
You should to follow established naming conventions, not just for readability purposes, but also so automatic introspection code works.
However that isn't really your issue because you have a standard getter (e.g. getName()), and that PropertyValueFactory can fall back to get the value from that.
You have code like this:
Never should you set a value initialized by FXML to a new value. Instead work with the existing value which is injected by FXML. What the code you have will do, is add additional new columns to the columns in the table which were already added by the FXML, which really isn't what you want.
There are lots of other issues with your code. For example, you should never have @FXML injected variables in an Application class. FXML will generate a new controller, but you can only have one instance of an Application class and that is generated by the JavaFX system at startup.
Your FXML should reference your controller class (use an fx:controller attribute on the root container to do this). You should actually have a separate class which is the controller class and has the @FXML annotations in it. The initialize method in the controller should initialize the UI. As all of then UI items you need are already defined in the FXML, you do not (and should not), create new versions of them anywhere (FXML will create instances of all the UI items you need). All you need to do is to wire the UI controls to your data. For your table, the small snippet of code below in the initialize method of the controller is the only thing that is needed to put data in the table:
In terms of Architecture, with your Browser interface, the JavaFX application class should not extend that. You should follow a single responsibility principle of design. The application class should only be responsible for launching the app, loading the initial stage and cleaning up resources on shutdown and nothing else (i.e. even in the final production version of the code, there wouldn't much else you would want to put in there other than perhaps starting up or shutting down a database connection pool if that is needed). Your controller class should probably just deal only with the UI elements and not the full functionality of whatever your Browser interface is, then you should have a BrowserService or BrowserImpl in another class which extends from the Browser interface and implements whatever that thing is supposed to do. Perhaps the Browser Interface itself should be split across multiple functions, such as a LoginService or SessionService, DatabaseConnectionService, DAO objects or other things like that, but I don't know enough about what you are trying to accomplish to really know about that. To tie browser implementation and the UI controller together, you could either set the browser service instance into the controller https://stackoverflow.com/questions/14187963/passing-parameters-javafx-fxml
or get the controller from the fxml loader and set that into the browser service and have that directly manipulate the UI elements in the controller (if you wanted a really tight coupling between the BrowserService implementation and the BrowserController). So, there are lots of architectural choices and discussing them all in detail is above the scope of what I would be prepared to do here.
Anyway, what I did, which may or may not help you, but at least creates a running app from which you can start to rework your implementation if you wish to, was take some of the code you have, reorganize it according to some of the conventions, corrections and principles mentioned above by Knute or myself, chop out of bunch of stuff which seems irrelevant to the current problem at hand, and create a working version of it which loads an updated version of your fxml file, wires some dummy data into it, then displays it.
After doing this, the FXML renders fine, the controller is initialized and the sample data (name "Rincewind", id "42") displays fine in the resultant table.