The problem here is that tableviews are designed to easily and accurately display the contents of you data-model and you've decided you don't want to do that. You're fighting the API.
The straight forward way to do this would be to put a check in numberOfRowsInSection
such that it adds one to the row count when you want to display the input row. Then in cellForRowAtIndexPath:
you will need to check if the table view is asking for the input row and return the appropriate type of cell.
From a UI design point, you might want to consider whether this setup is the best. This isn't a standard setup. Is the user going to understand that they can only edit the last row of the table? Will they understand they can't edit the other rows? Does anything in the UI tell them how all this works? Does the user have to scroll to the end of the table every time they want to add data? How long can this table grow? How will displaying a keyboard for the last row of the table affect how table scrolls?
I think it would be a better design to use a footer view to display the text field such that is is visually distinct from the rest of the table. It would be programmatically simpler as well. You wouldn't have to check if the table was asking for the last row every single time it ask for a cell.
Edit:
In thinking about it, perhaps a sectioned table would be simpler. Just put the special row in its own section (with or without a header.) That would simplify you handling of the rows that source from the dictionary because the row count in that section would always be the count of the dictionary. Likewise, you could just check the section attribute of the indexpath to know what cell to return for what row.