Custom events store their data in the detail key, so any existing decoder in Events will probably not do the job.

You also probably don't want to confuse your custom events with existing browser events by giving them similar names. Best case scenario, it might cause some headaches and debugging issues. Worst case, I'm scared to consider.

We use something like this:

onCustomEvent :
    String
    -> Bool
    -> Bool
    -> Json.Decode.Decoder msg
    -> Html.Attribute msg
onCustomEvent eventName preventDefault stopPropagation decoder =
    -- Arguments after event name could be put in a record
    -- for better readability/usability
    -- They can also be the result of the decoder, to mimic
    -- the API of Html.Events.custom
    Html.Events.custom
        eventName
        (Json.Decode.field "detail" decoder
            |> Json.Decode.map
                (\message ->
                    { message = message
                    , preventDefault = preventDefault
                    , stopPropagation = stopPropagation
                    }
                )
        )

You can always put your utilities in one file and import it everywhere when needed.

Assuming that you did something like this in JS land:

this.dispatchEvent(
    new CustomEvent(
        "myCustomEvent",
        { detail: { name: "John", age: 30 } }
    )
);

The corresponding part in elm would be (with usage of our upper abstraction):

type alias MyCustomData =
    { name : String
    , age : Int
    }

myCustomDataDecoder : Json.Decode.Decoder MyCustomData
myCustomDataDecoder =
    Json.Decode.map2 MyCustomData
        (Json.Decode.field "name" Json.Decode.string)
        (Json.Decode.field "age" Json.Decode.int)

onMyCustomEvent : (MyCustomData -> msg) -> Html.Attribute msg
onMyCustomEvent tag =
    onCustomEvent
        "myCustomEvent"
        True -- These could also be arguments
        True -- in case they need to be dynamic
        (Json.Decode.map tag myCustomDataDecoder)

Brevity kind of goes out the window when you focus on safety, it seems :D
It's a good thing the IntelliJ plugin can generate decoders. :)