If you've decided it's inappropriate to store the months as actual dates (and it certainly could be -- I'm not criticizing that decision), you want to maximize performance by storing your data in a format that is most efficient.
That is most likely storing the month as an integer.
For display purposes, say in reports, or on a form, you can display the month name using format. It's a little tricky, as there's no direct conversion (where "MonthField" refers to the field where you're storing the month integer):
Format(DateSerial(Year(Date()), MonthField, 1), "mmmm")
An alternative would be to have a table that maps a month integer to the month name, but that adds a join, and if the field can be blank, you'd have to have an outer join, and that's much more expensive performance-wise than an inner join.
Keep in mind that you'd use the Format() statement only in the presentation layer, i.e., as the controlsource of a control on a form or report. On forms you'd likely use a 2-column combo box for this purpose, so the user would see the month name, but the value stored would actually be the month integer. In that case, a table might make sense, but I'm not certain that it would have any real advantage over just typing in a value list -- it's not like this is volatile data, i.e., data that may need to be edited (which is the main reason you'd use a table in place of a value list)!
EDIT:
As @HansUp has pointed out, there's a MonthName() function in VBA (I didn't know it existed!), so that makes all the above way more complicated than it needs to be -- you could use that in the presentation layer without a need for a table or for the complicated Format() statement.