So you have three functions: one to assign a Person to a Contact, one to edit the currently assigned Person, one to create a new Person who is then assigned to a contact. The trick is to keep the user from confusing the three. Ideally, you want some convention that is easy to learn and applicable not only for Person but for any data object on a form (Contact or others in your app). Here are some options, all which would need to be tested (of course).
Button per Object. Your current design concept really isn’t that bad: have a button beside each object to explicitly support editing. Its main disadvantage is clutter, but that might be worth it for providing excellent self-documentation especially if your users don’t frequently use the app, and editing the Person from the Contact form is an important function. The hard part is labeling the button clearly. “Edit,” at least in English, may imply “editing” the association of the Person to the Contact, not the Person’s attributes. Maybe something like “Details”? Leave it implied that the Person’s details may be edited.
Object control. I’ve suggested that drill-down functionality be part of an “object control” –an icon before the name that the user can select to perform various functions on the object via a centralized toolbar/menu bar or context menu (e.g., copy, delete). Drill down is the default action achieved by double-clicking. It assumes users will see it like the icon for documents in a file manager and double click it to drilldown for editing/updating. This approach makes some sense in your case since you have two actions: drill down and Create new person. However, I anticipate there may be some confusion in making Create (new object) a toolbar/menu item, because it can be ambiguous if it creates a new Person or creates a new association with a person (e.g., the user may think that Create inserts a second Person line to allow a single contact to be associated with more than one Person).
Link. Underlined colored text is a strong clue that the control leads to more information on the object. The problem is that really the person’s name should be underlined, but you can’t do that in a drop-down. One option is to make the “Person:” caption a link, but users may think that only provides information about the Person field or class on the form (e.g., what counts as a “person”), rather than information on an instance of a Person. A better approach would be to show the Person name as a read-only text link, and put a drop down arrow button beside it to select the person. The user clicks the name to view/edit the Person, but clicks the button to assign the Person.
Pulldown Menu. If editing the Person from the Contact form is not that common –more a convenience than an essential function –then you could have a pulldown menu on the toolbar/menubar that opens the Person window. I say pulldown because the same menu would open any other form you have: Contacts, Organization, Projects, whatever. You probably need such a menu anyway. When no form is displayed, the Person menu prompts the user for the person’s identity (e.g., with a Search dialog), or it opens to some reasonable default (e.g., the last Person the user viewed). However, when a Contact is shown, the Person window opens to display the Person in the Contact –there’s only one, so it shouldn’t be ambiguous. Perhaps the user can then change the Person in the Person Window if it isn’t who they want to view/edit, which would not change the Person assigned to the contact. That’s good flexibility, but users may also be confused by it.
This one is trickier.
Button per Object. Your design is probably the best for self-documentation. Again, its main disadvantage is clutter, but it might be worth it. The key is getting the label right.
Object Control. I described this above and why I’m skeptical of how well it would work. But if you have multiple actions available for Person, it might be worth trying.
Create from Edit. You could integrate this functionality with any of the edit/view options from above. If the users click for edit/view when the Person field is blank, they’re presented with a blank Person window to fill out and create a new instance. Kinda makes sense. Title and label changes confirm a new Person is being made. If the Person field is not blank then edit/view opens the window for that person, but the window includes a button to create a new Person.
Type to Create. If the person’s name is the only required field, then maybe change the dropdown list to a combo box, and let the user simply type in the name of the new person. Saving the Contact form then creates a new Person instance with that name. Let them enter details about the person whenever through the Person Edit/View feature. The main risk is users accidentally creating the same person twice with slightly different name spellings resulting in two records for the same person. The chance of this can be reduced by providing some annunciation beside the field that the app recognizes the input as a new creation.
The Person Dropdown.. The Person Dropdown could include a Create New Person item either at the beginning or end of the dropdown list of existing Persons. Selecting this option opens the Create Person form. It’s weird for a dropdown list to open anything (that isn’t on the web), but it might be effective.
Nothing. If creating a new Person not part of the usual workflow for entering a Contact (usually users create Persons elsewhere), maybe you don’t want to support this from the Contact form at all. Instead, a Person is created however it’s usually created. If the user is entering a contact and realizes the Person doesn’t exist, they go through the standard person-creation procedure elsewhere. If all your forms are modeless (probably should be), this won’t mean much more work. It assumes the Person dropdown on the Contact form updates as soon as the user saves the new Person.