Need an Obj-c code review for core data implementation

without referring to your code, I think there is one pattern, that makes core data more fun but sadly isnt supported by Xcode out-of-the-box:

Have two classes for each model: one for automatic code generation — it will be jsut changed by Xcode — and on that inherits from the first, that can be changed and will never touched again by the machine after creation.

// for the machine
@class _Event : NSManagedObject
@end

// for human beings
@class Event : _Event
// what ever you need: pit it here
@end

a great tool to teach Xcode this pattern is mogenerator. mogenerator + Xcode4.x

Another similar approach would be to have categories on the Model class. But this is less powerful and needs more attention for importing.

Now to your code.

I dont see any reason to overwrite the setter. if apple says that you most likely will never be able to write as performant accessors as the provide, they probably are right. Instead you should create your own method, that will set up a object as need. you could overwrite save and similar methods, or access it via a wrapper class, that will set it up for you.

I plan to create a service class as a factory that manages the entities and their interactions with the context.

that sounds valid and could be the wrapper class mentioned above. But make sure, you create the model objects with initWithEntity:insertIntoManagedObjectContext:, as you want them in your context.

Core Data is a great and powerful framework. but beware: if you shoot yourself in the foot, most likely booth your legs will be gone.
2 Years ago I was working in a team where the Engineer responsible for persistency accidentally overwrote a internal method of NSManagedObject. It took him one week to find the cause and fix it by renaming his method. This line of code was probably the most expensive in the whole project. There-for another hint: prefix your custom methods.

I would refactor your code as follows:

@implementation CodeReviewClass

static NSArray *scoredKeys;

+ (void)initialize
{
    if (self == [CodeReviewClass class] ) {
        scoredKeys = @[@"fullSwings", @"putts", @"fairwayBunkers", @"greenBunkers", @"chipsOrPitches", @"rescue", @"wastedOrPenalty"];
    }
}

I asked a question about +[NSObject initialize] over on StackOverflow and got some great responses. The responses point out the canonical way to use initialize.

+ (id)codeReviewClassWithHoleNumber:(NSInteger)holeNumber insertInManagedObjectContext:(NSManagedObjectContext *)managedObjectContext
{
    CodeReviewClass *obj = [NSEntityDescription insertNewObjectForEntityForName:@"CodeReviewClass" inManagedObjectContext:managedObjectContext];
    if (obj) {
        [obj setHoleNumber:@(holeNumber)];
    }

    return obj;
}

I've seen this convenience constructor pattern more frequently with Core Data managed objects then the two-stage initialization used with NSObject. Particularly because the designated initializer (-[NSManagedObject initWithEntity: insertIntoManagedObjectContext:]) is pretty finicky. Definitely read NSManagedObject Class Reference - they give special treatment to overriding init. Obviously substitute your actual class name in for my placeholder text!

- (void)incrementItem:(NSString *)key
{
    NSInteger value = [[self valueForKey:key] integerValue];

    [self setValue:@(++value) forKey:key];

    [self recalculateScore];
}

Core Data properties are key-value coding compliant, and you don't have to use the will/did + Access/Change + ValueForKey: methods if you use the dynamically supplied accessor or mutator (KVC tries to use these methods).

-(void) recalculateScore
{
    NSNumber *current;
    int tally = 0;

    for (NSString *key in scoredKeys) {
        current = [self valueForKey:key];
        tally += current.integerValue;
    }

    [self setScore:@(tally)];
}

@end

Again, I opt to use the publicly exposed properties via KVC to calculate the tally. The rest of the changes are stylistic syntax.

Your score property could be marked as a transient property in the Core Data Managed Object Model, and calculated on-demand using the implementation of recalculateScore. This of course could get expensive if you calculate it frequently!