I know much more about Go than chess, so I don't know how accurate my guesses about chess endgames will be, but... I think chess tends to be at its simplest in the endgame (like Go), and there is little information in the endgame about how the rest of the game progressed (unlike Go). And, there are algorithms for winning (in some cases) that generalize to a large number of positions. E.g., if white has a Queen and a King, and black only has a King, unless the Q is about to be captured white will win, regardless of position.
In Go, the endgame is also the simplest part of the game, in that it is the only part of the game in which the score and the value of each move can be calculated very precisely, however position is everything, and you will never see two games end with the same board position. In chess, you can generalize many positions to what pieces remain, but in Go the only generalization is the score count and the number of points still remaining to be taken.
It would be utterly impractical to rely on whole-board level tables in Go, however many small areas of the board will fit common patterns, which are memorized by Go players and programmed into computers alike. A medium-level example would be bent four in the corner is dead, but you'll see that this relatively common position is not at all obvious to a beginner and comes with several caveats (no un-removable ko-threats, surrounding group must be alive with 2 eyes), and while relatively common, it is somewhat of a special case.
Something like knowing where to play to kill (or save!) bulky five (and many many other shapes) should be automatic for a human or computer.
Programming a computer to play good yose is a very hard problem, but is one of the few aspects of Go at which computers can beat professional Go players, as it is all calculation and, while difficult, the theory is well-understood. To do it effectively the program must be able to estimate the current score, identify the moves left on the board that are worth points, and sort them in order of worth---not trivial. This article might be a good place to start.
Summary: There is a place for systematic lists of positions in Go programs, but they won't be useful for whole-board positions. The program needs to be able to evaluate the life/death status of every group on the board, and it is in these one or two group positions that lists will be most useful---and they'll be valuable throughout the game. In trying to attack opponent's groups, your program's goal won't be just to recognize shapes from the list, but rather to force the opponent into shapes that it knows are dead, while maintaining live shapes itself. See also Common Corner Shapes.
In writing a Go program, I would give you the same advice as I would a person learning Go: start on a small board, even as small as 5x5 until you have the rules down. Move up to 7x7, and then stay with 9x9 for a long time before you even think of trying 13x13.
Good luck!
