There are several factors coming into play here; the GME code, the version of R, the version of the package(s) that GME is calling, your data and your syntax. You syntax looks consistent the GEM documentation but I would recommend storing your data in directories that do not have spaces in the path. I do not have your data in hand so I have no idea it that is an issue. The first ting I would do is update the versions of your R packages. To do this open the R console (in Windows 7 right click on the shortcut and select Run as "administrator"), then run the "update packages" option from the "Packages" menu. The other issue is your version of R. The CRAN effort is rapidly developing and version releases can introduce entirely new structures, which may be inconsistent with static code.
Many of the spatial packages in R are in (very) active development making it critical to stay current on the packages. Since Hawth Beyer does not provide detailed information on the structure of his code, it is difficult to know what dependencies to stay current on. My best guess would be: "sp", "rgdal", "spatstat", "maptools", "spdep", "ks", "ade4", "adehabitat" (the ade and ks packages are most likely supporting the Kernel functions). That said, this is also a good way to break existing code. Sometimes updates can break code, thus throwing an error, but it also possible for a update to cause code to behave differently and yield unexpected results.
Unfortunately, this all means that some R code cannot remain static. Occasionally when you attempt to install an older static package, R will not allow it because of major changes to R dependencies. Changes to package dependencies have also caused me serious headaches in some of the packages that I have written. I have no idea if GME is static or under active development with current versions of R and associated dependent packages, but this could potentially influence results.
I admit that R is a steep learning curve but it is well worth the effort. What you are trying to do is actually fairly straight forward using the spdep package, with many additional options for neighbor specifications. The spatial aspect of R is becoming quite mature and new functions/packages are coming on line frequently. This provides the capacity of utilizing more efficient or robust approaches as they become available. As an example; Roger Bivand has recently written a port to a C++ topology library. I found 100 fold increases in buffering speed compared to a function that I had written around the CircleStats package. Sorry to not have a silver bullet answer but as the saying goes "its complicated".
