There are a couple of issues with the code that you posted:
1. When updating a search document, the ID parameter used in the Update(id, options) method is the id of the search document itself not the id of the object. So you would first need to get the unique id of the specific search document for the item you are trying to update.
2. You can only add / update search documents for custom items only, not for existing / OOTB things like groups, blogs, blog posts, etc.
You ought to be able to accomplish what you are trying to do. In 7.0 it will be easier because via events we provide you with a copy of the search document before it is indexed so that you can make changes to it, like adding custom fields.
In 6.x and previous you have a couple of alternatives:
1. Create a custom search document of a custom type that includes your custom fields with the group's url, name, etc. By doing so you would basically be creating two items in the index for each group, the main one and your new custom one. It shouldn't be too much of an issue when searching specifically for the interests but both may show up when the search term matches the title. Another downside to this is that you would have to keep the custom entry synced up with the group so that the title and url are updated when the group is updated, your entry is updated when the group is removed, etc. You'll also have to use the same roles that the group uses so that your entry is only shown to those with permissions to see the group. You can get a list of roles with permission for a group by using the Roles List method of the in-process API: telligent.com/.../22179.roles-in-process-api-service.aspx
2. Another option, though not supported, would be to create a custom Group mapper (Inherits from DocumentMapper) that adds the custom fields to the Group's search document. This will let the existing group mapper do its thing but just add the new custom fields. And since you would be using the existing search index document you would not need to worry about keeping anything in sync - it will all be handled for you. The downside to this approach is that this functionality is changed in 7.0 and any customizations you use now will need to be changed when you upgrade to 7.0 or later.
One additional note is that when using custom fields, they are unrecognized and get treated like a "string" datatype by SOLR, which means that any search must be an exact hit - casing and all. If you want the term to be treated differently, e.g. like a "text" field, you will need to add an entry for the field to the schema.xml file.
Your best bet at this point will be to wait until 7.0 if you can because it will be much easier to accomplish what you're trying to do in an API-supported manner. If you cannot wait then either of the two above should meet your needs, but each has its own pros and cons.