In general, processors do not detect and special case identity elements (zero addends, zero shifts, one multiplicants, one divisors) or zero multiplicands.
Addition is typically extremely inexpensive; a processor complex enough to handle the identity special case would typically have enough execution width that skipping an occasional addition would not improve performance much. The latency benefit is also low (e.g., zero cycles versus one cycle). The frequency with which such occurs would also be low, so the net benefit would be small at best.
With the noteworthy exception of zeroing idioms, a zero result would be detected near the end of the execution cycle. At that point, the decision to execute the dependent operation has already been made and, in a traditional out-of-order design, the expectation of a result of the dependent operation in one cycle has been used by the scheduler to schedule dependent operations. Dynamically converting the addition to a copy at execution might save a little energy, but detecting the special case of an addition and making the decision for many operations (the common case) would probably use more energy overall.
Zeroing idioms are recognized in decode and handled in register renaming. This removes most of the added cost of zero detection and provides the information early enough that instruction scheduling can be adjusted. As mentioned in this Real World Technologies forum post, Intel does exploit this special case to provide lower latency for some indexed addressing cases where the index has been zeroed using a zeroing idiom.
Because no-page-crossing speculation (and its misprediction recovery mechanism) is broadly useful, adding this special case may have been very inexpensive. Even though such zero-indexed loads would be somewhat rare (e.g., the first load in a loop), the extra cost would be small and load latency is often critical. (While a compiler could convert the first iteration of such loops into direct base + offset addressing, the code bloat effect is obvious and the optimization rather microarchitecture specific. Similarly, function calls with explicit zero operands could be handled specially by the compiler with longer compile times and possible code bloat.)
Special casing addition by an explicitly zeroed operand could be handled in rename, but as noted above the benefit would be modest because additions are cheap in latency and issue width. (Multiplication by an explicitly zeroed operand would be similar, though the benefit would be greater.)
Multiplication is a different; multiplication generally has high enough latency that early output of the result would be easier to implement in terms of scheduling. With a fully pipelined multiplier, throughput would not be improved with early output, but latency would be improved. (In theory, throughput could be improved in a fully pipelined multiplier if two short multiplications were executed in parallel, a kind of dynamic SIMD. Since such would also involve more operands, the extra complexity would not be likely to be justified.)
Motorola's (now Freescale) PowerPC 750 had an unpipelined multiplier and supported early out when a specific operand was small (not just one or zero). This improved both latency and throughput.
While some ISAs have detection of zero results at no additional cost (setting flags on many operations) and this would also make detection of small positivie numbers easy (the most significant bits being zero is part of the specific zero detection), if the potentially special value has a short life (the common case), the opportunity for exploiting such special cases would be small.
If the special value is recognized earlier than other operands are available (or a structural hazard delays start of execution), this extra delay could in theory be exploited to strength reduce the operation before it starts execution. When the special value is recognized and the scheduler has decided not to execute the operation (data or structural hazard preventing execution or even energy management throttling execution), the operation could be strength reduced before the next scheduling opportunity. This does not seem likely to be low hanging (nor high value) fruit.
Other tricks might be used to hide the scheduling loop latency to facilitate such dynamic strength reductions, but professional hardware designers have not yet chosen to perform such strength reductions so the cost and benefit tradeoffs are presumably not favorable (under expected conditions).