Adding a type to the stdlib would indeed require a proposal, yes, and I appreciate the offer. We do, however, have quite a few enhancements that we're interested in making to Codable, and from a design perspective, I think they would benefit most from being designed together.
The implementation of this will be really easy (it's almost 100% complete above! 
), but getting the naming right and making sure the ergonomics are there (I'm going to respond to @hooman above regarding dynamic lookup) is going to take time, which I don't think we'll have for Swift 5. I for one, would actually be opposed to adding a bare type called Unevaluated to the standard library because it is vague and unhelpful; on the other hand, we cannot nest it within Encodable or Decodable (because they're protocols, and also we don't want to split the type up between them) nor Codable (because it's just a composition of protocols).
In all, I think there's a lot more exploration to be done in the Codable space and this is just one piece of what I've been thinking about; in the meantime, AnyCodable should certainly work for you.
For what it's worth, I'd like to push out pitches at the very least for a few such enhancements toward the end of Swift 5's release cycle (or the beginning of Swift 6), time permitting. Feedback on such pitches would be very helpful. 